Re: X Rendering and GNU Classpath

[graydon hoare]

Tom Tromey <address@hidden> writes:

> >>>>> "Sascha" == Sascha Brawer <address@hidden> writes:
> 
> Sascha> As you might know, the Java2D API [2] is very much oriented
> Sascha> at the PDF 1.4 drawing model. Implementing it via the X
> Sascha> Rendering Extension thus seems like a good choice.
> 
> FYI, Graydon Hoare (CCd) has been working on this very thing
> recently.  I don't know if Graydon follows this list, but maybe he
> can comment on what he's been up to.

yes, sorry, I haven't been reading the classpath list. I shall add it
to my feed.

for the past 3 weeks I've been writing parts of java2d, for
work. specifically I have written a partial java.awt.Graphics2D peer
object, called gnu.java.awt.peer.gtk.GdkGraphics2D, which supports
the java2d image model by building cairo[1] surfaces on the underlying
GDK drawables and painting through the cairo library. I have also
updated and fleshed out some parts of the geometry and image loading
classes.

currently the peer object supports filled and stroked paths (lines,
cubic and quadratic splines); clip regions; stroke attributes like
width, join and end types, miter limit; the 12 porter/duff compositing
rules (with alpha channel); progressive image loading and painting
through GdkPixbufLoaders; affine transformations; and offscreen images
for conventional awt-style double buffering.

most of my work so far is buffer and context management, glue code,
and passthrough methods to cairo. it does all the hard work. rendering
speed is not terribly good yet (a few hundred small geometric
primitives / second on my system) but the image quality is excellent.
it builds with gcj (in my tree) as part of the gtk peer objects. 

I have not committed it yet because I think it's not quite ready to
supplant the role of the Graphics peer object, but I suppose I could
commit it in a disabled state, if people want to look.

notably absent are custom strokes, custom compositing operators,
stroke -> shape conversions, etc. the cairo implementaiton currently
keeps a fair amount of this state to itself. it is not clear how
mainstream the requirement for these is, but I'll hack things into
place as necessary. I've talked to carl on IRC a bit, and he has
indicated that some -- perhaps not all -- of the requisite bits may be
exposable or queryable. I think a compromise will be possible.

shortly I expect to begin playing with text (as soon as carl or keith
commit a working version of the text API carl recently posted). I am a
little concerned that sascha's work on java's text rendering API may
duplicate a lot of work: as a community we have already invested many
person-years into developing font rasterizers, font configuration
managers, glyph hinters, unicode layout and glyph shaping systems. I
feel we should reuse pango, fontconfig, and freetype / xft where
possible, through simpler JNI bridging.

-graydon


[1]: cairo is the new name of Xr, which is a client-side library for
painting on X servers (and, in the future, other surfaces) using the X
RENDER extension when available, and falling back to client-side
operations when it is not. see http://www.cairographics.org. it is
written by keith packard and carl worth.