[OpenJDK 2D-Dev] Best way organizing XRender additions for theX11 pipeline?

Carl Worth cworth at cworth.org
Wed Dec 5 17:53:37 UTC 2007

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20071205/a45f6032/attachment.bin>

More information about the 2d-dev mailing list