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
_______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
