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 <[EMAIL PROTECTED]> 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 _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
