AWT hacks (Was: [cp-patches] FYI: Only prepare GtkImages in GtkToolkit)

[Mark Wielaard]

Hi (moved to classpath main list from classpath-patches),

On Mon, 2005-05-02 at 09:26 +0200, Robert Schuster wrote:
> Mark Wielaard wrote:
> > Robert pointed out a regression that happened with almost any free swing
> > based application when using cairo with gnu.java.awt.peer.gtk.Graphics
> > set to Graphics2D. A cast to GtkImage made all calls to prepareImage
> > fail. This patch only prepares GtkImages and just assumes all other
> > images are already prepared.
>
> isnt that considered a hack?
> 
> I would like to see it documented like one if so. This would IMHO help
> the brave persons who will tear current AWT implementation apart and
> re-engineer it. :)

Yes, I guess it is a bit of a "hack". Thanks for picking it up.
In this case it was also just a bug and a regression since we didn't use
to call prepareImage in a couple of places that we do now.
Unfortunately with Graphics2D support we then pass a BufferedImage, not
a GdkImage. If someone thinks this specific issue in
GtkToolkit.prepareImage() should be fixed in some other way please
respond to the original thread on classpath-patches. This response is
more about trying to define how we go forward with AWT, gtk+ and cairo.

We recently discussed this a bit on irc. I'll try to summarize that
discussion here to see if people agree and to see if we can get some
idea of when what work needs to be done. Thanks to Sven for going
through this with me. Any mistakes in this summary are mine.

AWT 1.1 and AWT 1.2 are completely different. The GDK and Cairo peers
are completely different. In the long run we have to kick out GDK for
cairo and AWT 1.1 for AWT 1.2 at the same time. This means no more
GdkImage and no more Graphics, only Graphics2D. No more ImageObserver
crap except for reverse-compatibility with animated gifs. At the moment
we have a lot of kludges (like the above hack) to get our current peers,
which are basically AWT 1.1, to work with real-world applications (some
of which expect Graphics2D and/or BufferedImages).

What we want is have a 1.2 Graphics2D and BufferedImage model with
backward compatibility hacks for some of the old Image and ImageTracker
stuff. The question is how to get there. Do we temporarily create
(hacked) GdkImage that is a BufferedImage and work from that? Or do we
wait till cairo and gtk+ are mature enough and switch at the same time.
I am hoping that Sven and Thomas will respond to this message and fill
in details on how they think the best way of going forward is.

I think targeting a new gtk+ and a cairo 1.0 release is easier then
adding BufferedImage support to GdkImage. But looking at the RoadMap and
TODO of cairo it looks like cairo 1.0 is still a long way off:
http://cvs.cairographics.org/cairo/ROADMAP?rev=HEAD
http://cvs.cairographics.org/cairo/TODO?rev=HEAD

On the other hand Owen Tayler has been doing reviews of java-gnome and
the cairo bindings this last week:
http://lists.freedesktop.org/archives/cairo/2005-April/003783.html
http://java-gnome.sourceforge.net/cgi-bin/bin/view/Main/JGDiscussionMemoryManagement
So it might make sense to take this oppertunity to lay down a plan for
the future needs of our gtk/cairo awt peers and ask him for input on it.

I know Thomas and Sven have thought about this a lot more then me so I
am hoping they could reply to clear up any mistakes/misconceptions I
have made in the above.

Cheers,

Mark

P.S. the java-gnome developers will have a meeting about the
JGDiscussionMemoryManagement on irc.gimp.org in #java-gnome at 20:00 GMT
today (May 2 2005).

signature.asc
Description: This is a digitally signed message part