Tom Tromey <[EMAIL PROTECTED]> writes: > graydon> subsequently the structure of the work so far is not as open > graydon> to tinkering on the java-side of the JNI as the java2d APIs > graydon> might imply. > > I assume this is a temporary problem, and not a permanent one?
I think the issues are "mostly" temporary, yes, but it will be a long and tiring road to remove every conceivable limitation. it's a big body of code with a lot of weird ways you *could* use it. I'm expecting to eventually provide glyph -> path, path -> stroked outline, path geometry feedback, custom composite operators, etc. back up at the java level. all via feedback from cairo. but these are not present yet, and occasionally there is something implied about the inner workings which is not obviously essential and might be an implementation option. it's sometimes hard to tell. for example, say I support Composite objects, so that even in the general case I can accept a user-written Composite and do a pixel read-composite-write loop. I intend to do that much, because it's needed even for compatibility with bitwise xor compositing, which the old Graphics object supported. but the Graphics2D API has both a get and set method for the "current Composite". the implication is that a Composite object is being used to do composite operations in our GdkGraphics2D. But *most* of the time, I have no intention of shipping pixels back and forth to java, I want cairo to do a fast composite, within the display server if possible, using X RENDER packets. so suppose when asked for the GdkGraphics2D's current Composite object, I return a GdkComposite which just stores a description of the current cairo composite mode (say: an integer), so that it can be stored and set again in the future. if someone takes that GdkComposite and provides it to a sun Graphics2D, or some other function which uses a Composite, it will not perform the composite mode in that foreign context. it's just a memento for GdkGraphics2D. if need be, we could write a java implementation of the 12 porter/duff rules for all the various color models, but my current plan is to not do so. cairo already knows how. similarly, it is not clear when it is necessary to work with every possible colorspace or every possible pixel packing mode, nor is it clear which sort of precision a transformation between spaces or modes should occur with. it is also unclear how precise the approximate geometry methods need to be -- several are documented to be approximate -- so there is a chance of providing something which disappoints a java2d-using application. > Our preferred route is smaller self-contained patches. Sometimes that > isn't possible, or desirable -- sometimes it makes more sense to have > one big patch. It's your call on that sort of thing; anything > defensible is fine :-) ok. mostly this is new code, which I'm only intending to commit for storage, not activate yet. > Post to java-patches. If there's something likely to be > controversial, let's talk about it sans patch on the classpath list. > Mostly I'm wondering how this interacts/interferes with other java2d > implementations, other platforms, etc. (I'm sure this was already > covered and I forgot the answer. Blah.) I think it will interoperate not-very-well with other java2d implementations. it shouldn't *clobber* them -- it's confined to the gnu.java.awt.peer.gtk package -- but similarly I doubt it will be able to exchange a great many low level objects with them. there's going to be a cutoff point where the object is represented by a C/GTK/cairo amalgamation, and it just won't work in another rendering pipeline. see above elaboration. -graydon _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
