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. /Sven > > Hi Everyone, > > Following a very brief discussion on irc with Michael we thought that > broader input would help resolve: > > https://savannah.gnu.org/bugs/?func=detailitem&item_id=12211 > > Namely, should GdkGraphics extend Graphics (as it does now) or > Graphics2D? > > The argument against (corrections please) is that Graphics2D implies > more functionality than is currently available either in our AWT/Swing > or in the underlying native layer. > > The argument for is Sun's (and IBM's) doing unfortunately. Since > 1.2(?) > JComponent.paint() gets passed a Graphics2D object in the majority of > cases[1] and people are writing production code such as the following > example habitually. > > public void paint(Graphics g) { > Graphics2D g2 = (Graphics2D) g; > g2.draw(new Rectangle()); > } > > Worse is that publications teaching usage of Swing encourage this > usage. > > I propose that GdkGraphics be made to extend Graphics2D with dreaded > stub methods to make it behave like a standard Graphics instance. > > I realise that subbed classes hide incomplete implementations at > compilation time[2] (heaven knows this has been discussed heavily in > the > past) but what concerns me now is making this work at runtime. > > Comments welcome! :) > > Best regards _______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
