[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    [OpenJDK 2D-Dev] Best way organizing	XRenderadditions	for	theX11 pipeline?
From:       Dmitri.Trembovetski () Sun ! COM (Dmitri Trembovetski)
Date:       2007-12-07 19:27:28
Message-ID: 47599EA0.3080907 () Sun ! COM
[Download RAW message or body]


   As a matter of fact, Chris Campbell from the 2D team
   did an initial investigation on XRender pipeline
   a while back (I just found an internal wiki page with
   the results of that investigation).

   I hope he doesn't mind me posting his thoughts here:
It doesn't appear that we can simply extend the existing X11Renderer code. XRender \
only knows how to fill rectangles,  trapezoids, and triangles, so we'd have to do \
some restructuring so that we issue other types of primitives in terms of  these \
operations. Probably need a complete rewrite of X11Renderer.

Also, XRender operations speak to a "Picture", which can be derived from an existing \
Drawable, so we'd need to somehow  keep a reference to a Picture in the X11SDOps \
structure.

It appears that XRender operations are not affected by basic Xlib GC state (such as \
color, clip region, logic op, etc),  so we'd need a separate state validation path in \
X11SurfaceData (or perhaps a subclass?) that handles things like  setting the current \
clip region, composite op, etc.

The OpenGLPipeline deviates slightly from the ColorModel? spec in that it treats \
opaque destinations as premultiplied.  (This is not allowable under the current \
ColorModel? spec, but so far no one has called us out on it. We were hoping to  relax \
the spec in Mustang but we never go around to it unfortunately.) We will probably \
need to do something similar for  this new pipeline, because we will be blending \
premultiplied components to an opaque destination.

A good place to start would be to try to implement MaskFill using XRender. We could \
cache a small (32x32) Picture in the  PictStandardA8? format to use as the mask.

   And, we have a couple of bugs already filed for the
   use of XRender:
     * 6307603: [X11] Use RENDER extension for complex operations done in software
     * 5086814: RFE: Java 2D: consider Xrender for anti-aliased text on remote X11

   Thanks,
     Dmitri
   Java2D Team

Dmitri Trembovetski wrote:
> 
> 
> LOUD, Ben wrote:
> > > > Meanwhile, if instead of "paths" you've actually already got 
> > something
> > > > tessellated and just need it to be rasterized, then sure, you can 
> > call
> > > > into XRenderCompositeTrapezoids to do just that if you'd like.
> > 
> > ahh ok this is interesting. I see your point. I've been speaking under 
> > the assumption that X Render wouldnt be involved in this step. I 
> > believe in Java2D, all the work of producing coverage values is always 
> > done in software, and OGL or whatever only does the compositing. I 
> > hadnt considered that Render could accelerate both.
> 
> Yes indeed, in Java2D this part is done in software.
> However, I think that it would be nice to start out with
> just XRender pipeline (may be sitting on top of the
> x11 pipeline - the same way the old ddraw pipeline
> extends gdi one).
> I'm not really familiar with XRender myself so I don't
> know if you could mix X11 and Xrender rendering to
> the same drawable.
> 
> I think we'll need something to address performance issues with
> apps using AA rendering and alpha compositing on X.
> We've been careful not to use too much of both in our
> built-in Swing L&Fs, but with the introductions of
> Nimbus that goes out of the window - it is fully vector
> graphics driven, with AA and AC everywhere.
> The performance on X11 will suck as a result of that,
> unfortunately.
> 
> I have my doubts about fully integrating Cairo at this
> point (just because it would be much more extensive
> undertaking) but it should be relatively straightforward to
> implement an XRender pipeline.
> 
> You can follow the example of x11 and opengl pipelnes.
> 
> Unfortunately you don't have access to the new D3D
> and opengl pipelines which we're working on for
> 6uN - we have improved code sharing between the pipelines
> (d3d, ogl) a lot, generalized a bunch of stuff, so it might have
> been easier to start from there.
> We could forward port the shared pieces to openjdk once
> we have some breathing time.
> 
> Anyway, the I would approach this would be something like this.
> 
> You'd need to create a SurfaceData subclass (say, XRSurfaceData) with
> appropriate SurfaceType. See OGL/GLXSurfaceData for
> the inspiration. Whether your surface type would be a subtype
> of X11* surface types depends on whether you can do x11
> rendering to XRender surfaces (Pictures?).
> 
> Then you'd define the pipes and blits which render to
> and from your surfaces (see OGLRenderer, OGLBlitLoops).
> 
> You'd need to create appropriate SurfaceManager (Volatile- and
> Caching-) so it would create surfaces of your type
> for Buffered- and Volatile-images, and BufferStrategy.
> (see GLXVolatileSurfaceManager). Also see SurfaceManagerFactory -
> this is where SurfaceManagers are created.
> 
> Also, you'd need to create your own GraphicsConfiguration
> subclass (see GLXGraphicsConfig) so that the window surfaces
> of your type can be created.
> 
> There's tons more details, of course. But this is a
> general direction.
> 
> Thanks,
> Dmitri
> 
> 
> > ------------------------------------------------------------------------
> > *From:* 2d-dev-bounces at openjdk.java.net on behalf of Carl Worth
> > *Sent:* Thu 6/12/2007 4:23 AM
> > *To:* LOUD, Ben
> > *Cc:* 2d-dev at openjdk.java.net
> > *Subject:* Re: [OpenJDK 2D-Dev] Best way organizing XRenderadditions 
> > for theX11 pipeline?
> > 
> > On Wed, 5 Dec 2007 21:48:36 +1030, "LOUD, Ben" wrote:
> > > Wow, Carl Worth himself! Great to see you on the list. Cairo no
> > > doubt is a wonderful package, a true gem of free software.
> > 
> > Blah, blah, blah...
> > 
> > > All i meant by my "high level" comment was that its a complete top
> > > to bottom graphics package, when really the only part that OpenJDK
> > > desperately needs is one part of the pipeline, the part that
> > > rasterises paths to produce masks.
> > 
> > I don't disagree that cairo is high-level and likely quite similar to
> > the existing OpenJDK Java2D interfaces.
> > 
> > But as for "rasterizing a path to produce a mask", that isn't an
> > operation that Render provides at all, and it's also not something
> > that is hidden in layers inside cairo. You can get at an efficient
> > means of doing that with Render by calling into existing cairo
> > interfaces just fine.
> > 
> > Meanwhile, if instead of "paths" you've actually already got something
> > tessellated and just need it to be rasterized, then sure, you can call
> > into XRenderCompositeTrapezoids to do just that if you'd like.
> > 
> > But note that there's a big difference between just calling
> > XRenderCompositeTrapezoids to get rasterization and using Render
> > efficiently. For one thing, as suggested by its name, that call can do
> > both rasterization and compositing, (potentially with accelerated
> > support from the graphics hardware), so you're not winning by using it
> > only or rasterization.
> > 
> > > I wonder how difficult it would be to factor out Cairo's
> > > rasterisation and stroking code so we could just use that. We
> > > wouldnt need its compositng, font support, SVG and PDF backends
> > > etc. etc. Of course I know zero about Cairo's internals but if its
> > > feasible, it might be worth a look. I'd love to see it happen.
> > 
> > Here, I'm totally lost. Things like the SVG and PDF backends are the
> > lightest things in cairo, (no dependencies at all, for example), so
> > they should be the least of your concerns. Meanwhile for
> > "rasterization and stroking" the _code_ that is in cairo---the
> > software implementation in pixman actually---isn't the most
> > interesting part. It's not the fastest rasterizer around, so you'd
> > be making a big mistake to do a bunch of work to try to extract
> > it. Instead, what is interesting about cairo's rasterization is the
> > interface to get at faster underlying systems. In the current
> > conversation you only care about one target (X Render) but as above,
> > calling into cairo for rasterization alone should work fine. There's
> > no need to factor anything out.
> > 
> > > I doubt we'd need cairo to take advantage of X Render though. That
> > > doesnt sound to me like the difficult part. I would think it would
> > > similar to what they've already done for OGL and D3D.
> > 
> > There are parts of using Render that are a fair amount of work. For
> > example, getting efficient text output through Render requires the
> > client to manage a server-side cache of glyph images, etc. Maybe
> > that's similar to what you've done for OGL and D3D as you say. But
> > there's not strictly any need to write new code for that. But don't
> > let me get in your way---please write whatever code you enjoy.
> > 
> > So I'm just trying to say that cairo exists, and should still work
> > well for the _original_ purpose of cairo, (provide a simple interface
> > for getting at X Render functionality), even if you just ignore
> > everything else that cairo can also do.
> > 
> > -Carl
> > 
> > "Warning:
> > The information contained in this email and any attached files is
> > confidential to BAE Systems Australia. If you are not the intended
> > recipient, any use, disclosure or copying of this email or any
> > attachments is expressly prohibited.  If you have received this email
> > in error, please notify us immediately. VIRUS: Every care has been
> > taken to ensure this email and its attachments are virus free,
> > however, any loss or damage incurred in using this email is not the
> > sender's responsibility.  It is your responsibility to ensure virus
> > checks are completed before installing any data sent in this email to
> > your computer."
> > 


[prev in list] [next in list] [prev in thread] [next in thread]