On Sat, 2005-03-05 at 17:46 +0100, Sven de Marothy wrote: >Hello, > >Currently we have a Cairo-based Graphics2D peer and a GTK-based Graphics >peer. > >The way I understand it, the plan is to throw out GtkGraphics completely >and make the Cairo-based Graphics2D peer the default as soon as Cairo >becomes integrated into GNOME, which is scheduled for this year. > >The way I see it, just adding stub methods might cause more problems >than it solves. Whereas implementing them would be a waste of effort >which could be better spent on improving the Cairo peer instead. >(And the Java2D support in general) > >It's not quite as simple as just adding the missing methods either. >Java2D is basically a completely different thing, which Sun rather >klugily grafted onto the existing API. So it's not just a question of >missing methods but a rather different architecture. The GtkGraphics >implementation can get away with doing nasty things internally like cast >Image to GtkImage. It does quite a lot of nastiness like that, since the >original Java 1.0/1.1 model is much more abstract. This won't work with >Java2D which has BufferedImage, and so on. > >So, IMHO, trying to turn the Graphics peer into Graphics2D will just add >to the kluginess. Better to do the proper thing and throw it out as soon >as it's practical to do so, and put our effort into Graphics2D and >Cairo. >
Very well said. Tom _______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
