status of java2d-on-cairo

[graydon hoare]

Tom Tromey <tromey@redhat.com> 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