Re: X Rendering and GNU Classpath

[graydon hoare]

before I respond point-by-point, I'd like to clarify my position in
general, so we're not arguing over language: my specific goal is to
support the java2d API on a free java system in as short a timeframe
as possible. this goal is based on a work contract, not personal
interest. to me, this implicitly includes C code via JNI -- part of
the java spec -- so long as it's free and portable. so whenever that
saves time, it's what I'll do.

as far as portability goes, GTK+ is portable to non-X11 systems (GDI,
aqua, directFB), as are all the other libraries I'm discussing. 
nothing in this discussion is X11-specific, non-free or non-portable. 
it's just written in C.

Sascha Brawer <address@hidden> writes:

> Stroke -> Shape conversions: IMHO, it would be good to have Java
> code for this. It seems something rather central that would also be
> useful for porting the code to other platforms. But this is just my
> personal opinion, which of course might be biased by my needs.

carl suggests that cairo will be able to feed this information back up
to us.

> Could you describe how you handle image buffers? If I may express a
> wish, do you think it might be possible to access the raster data
> through the java.awt.image framework? For example, this would allow
> to eventually use javax.imageio for image conversions.

images loaded from files and offscreen drawables are carried in
java.awt.Images. the pixel producing methods of offscreen drawables
don't currently feed any pixels (to a consumer) but they could be made
to do so. the producing methods of images loaded from files do feed
pixels, so you can load the data from eg. a PNG or JPG file.

> If you manage to expose the X Render pictures (or whetever Xr/Cairo uses
> as an abstraction of those) through java.awt.image.Raster, custom
> compositing operators should be doable.  I assume the main problem would
> be remote X11, because sending XImages across the network is expensive. 

no, the X Render pictures can be pulled (via XImage) to client side;
it's slow but it's correct, then you have a byte array. the main
problem is different: figuring out which spans of pixels you're
supposed to be compositing. cairo doesn't currently have a "callback"
interface for compositing. I'm trying to talk carl into supporting
it. there are other possibilities of course but I think that would be
easiest. the hardest approach is to manually write another path ->
scanline converter in java. I hope it doesn't come down to that.

> Actually, I would be most interested in hearing about how you plan to
> handle the tricky parts.  IMHO, this is not just a question of hacking...

ah.. it seems to me that all the necessary information and
functionality is present *somewhere* in existing imaging and rendering
libraries; I think it is mostly just a question of hacking to move the
information from where it exists to where it is needed.

> To give a concrete example, I think it should be possible to implement
> GlyphVectors so that the work which is specific to a concrete font
> subsystem gets delegated to an interface. 

I was planning to make a pretty lightweight object for this --
implementing the GlyphVector interface directly -- which wraps an
AffineTransform and a PangoGlyphString. from that you can drill down
through an FT_Face into an FT_OutlineGlyphRec (for the outline), and
otherwise compose glyph vectors through the normal pango pipeline, and
render them via cairo. I'm not sure there's much need for further
decomposition and factoring, though you're welcome to propose
something.

-graydon