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
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
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
* 6307603: [X11] Use RENDER extension for complex operations done in software
* 5086814: RFE: Java 2D: consider Xrender for anti-aliased text on remote X11
>
>
> 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@... on behalf of Carl Worth
>> *Sent:* Thu 6/12/2007 4:23 AM
>> *To:* LOUD, Ben
>> *Cc:*
2d-dev@...
>> *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."
>>
attachment0 (196 bytes) 