Hey, I'm not sure I quite support this yet, since it does mean losing some existing functionality. (For instance, drawing a dashed line) (Not that I don't hate the Cairo peer mess as much as anyone else..)
What I think I'd really prefer for the time being would be to keep the Cairo Graphics2D around a bit longer and just bump GtkGraphics up to Graphics2D-using-AbstractGraphics2D. Would that be OK? /Sven On Sat, 2006-05-20 at 05:43 -0400, Thomas Fitzsimmons wrote: > Hi, > > This is a work-in-progress patch to provide a GDK backend for > AbstractGraphics2D and also to ready the codebase for further Java2D > development. > > It turned out that making a GDK "backend" was (almost) as simple as > moving GdkGraphics under AbstractGraphics2D in the inheritance > hierarchy. Graphics-using applications will see little change in > performance/correctness with this patch, since GdkGraphics overrides all > of AbstractGraphics2D's Graphics methods. > > I also removed all mention of GdkGraphics2D and Cairo. If it turns out > that we can accelerate AbstractGraphics2D with Cairo methods, then all > we'll need to do is bump the GTK release requirement to 2.8 (which > brings in Cairo headers and libraries by default), and move any code we > need from GdkGraphics2D into Graphics. For now, I wanted to eliminate > the complexity of --enable-gtk-cairo and > -Dgnu.java.awt.peer.gtk.Graphics while we experiment with > AbstractGraphics2D. > > As you can see by commenting out GdkGraphics.fillRect (which causes > AbstractGraphics2D's fillRect to be activated), pixel colors are all > wrong. I haven't investigated why yet. > > Comments? If people don't consider this too drastic, I'll finish it off > and commit it this week. > > Tom
