classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AWT hacks (Was: [cp-patches] FYI: Only prepare GtkImages in GtkToolk


From: Sven de Marothy
Subject: Re: AWT hacks (Was: [cp-patches] FYI: Only prepare GtkImages in GtkToolkit)
Date: Tue, 03 May 2005 01:22:47 +0200

On Mon, 2005-05-02 at 18:09 +0200, Mark Wielaard wrote:
> 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.

Note that this (animated gifs) doesn't work currently. But ImageObserver
is used to update the Button frames on the JDK, and I think we should do
it the same way too. (Someone out there may have their own animated-gif
widget utilizing this)

> 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. 

Right.

> 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.

No, IMHO it's best to wait and do this at the same time. Graphics2D and
BufferedImage are both AWT 1.2. Really, allowing any part of AWT 1.2 to
run on the GTK peers will just set us down that slippery-slope of trying
to support two fundamentally different ways of doing things, and result
in ugly code and wasted work. As I've said before: Better to spend that
time improving the cairo peers. 

Basically what's getting replaced is exactly this: Imaging and Graphics.
Note at the moment a lot of awt.image doesn't work, and the remaining
parts might need to be rewritten later to see if we can speed things up.
Cairo needs to get better, and our code needs to utilize it better.

> 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

But what is the alternative? I don't really see one except doing a
pure-gtk/gdk implementation of AWT 1.2, which isn't a very good idea.

> 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.

Definitely. And we need to work out something on printing. I've been
meaning to sit down and work out a proposal, and I've done a little work
on that, but I've been waiting for Cairo a bit there too. 

/Sven





reply via email to

[Prev in Thread] Current Thread [Next in Thread]