Re: [cp-patches] FYI: JComponent fix

[Roman Kennke]

Hi Robert,

> I have a question/suggestion to this piece of code:
> 
> >    protected void paintComponent(Graphics g)
> >    {
> >      if (ui != null)
> > -      ui.update(g, this);
> > +      {
> > +        Graphics g2 = g;
> > +        if (!(g instanceof Graphics2D))
> > +          g2 = g.create();
> > +        ui.update(getComponentGraphics(g2), this);
> > +        if (!(g instanceof Graphics2D))
> > +          g2.dispose();
> > +      }
> >    }
> >  
> You said the reason for creating the new Graphics2D object is to
> preserve the state of g. However I find the solution inappropriate. The
> "right way" of doing this would IMHO be using getTransform() (and
> setTransform() afterwards).

The spec says:
<<We pass the delegate a copy of the Graphics object to protect the rest
of the paint code from irrevocable changes (for example,
Graphics.translate).>>

So should we do. The problem here is, that create() could create too
many Graphics objects during 'big' paint requests. At Aicas we solved
this problem in Graphics itself. When a Graphics object is created with
create() and later dispose()-ed, the dispose method attaches the
Graphics object to its parent (the Graphics object that created the
child). If there is a Graphics object requested later on this same
parent, it can reuse the cached Graphics. I don't know if that is
possible to do with our Graphics.

I cannot explain why the create() call is disabled for Graphics2D.
Looking at the ChangeLog is seems that Ziga Mahkovec introduced that on
2005-06-27. Ziga, maybe you could elaborate a little on this?

> Btw: In the future all Graphics instances will silently be Graphics2D
> instances (just as they are in the reference implementation since >=
> 1.2). A comment that explains this for future changes would be nice.

I don't know. This has nothing to do with Graphics vs. Graphics2D,
except that the copying is disabled for Graphics2D (which it should not
IMO).

/Roman