Tom Tromey <[EMAIL PROTECTED]> writes: > >>>>> "Sascha" == Sascha Brawer <[EMAIL PROTECTED]> 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. _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
