classpath
[Top][All Lists]
Advanced

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

Re: GdkGraphics extending Graphics2D?


From: Sven de Marothy
Subject: Re: GdkGraphics extending Graphics2D?
Date: Sat, 05 Mar 2005 17:46:54 +0100

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





reply via email to

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