Re: [cp-patches] FYI: JComponent fix

[Ziga Mahkovec]

On Thu, 2005-06-30 at 12:38 +0200, Roman Kennke wrote:
> > 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?

This code used to live in getComponentGraphics(), whose contract is:

"Returns the graphics object used to paint this component. If
DebugGraphics is turned on we create a new DebugGraphics object if
necessary. Otherwise we just configure the specified graphics object's
foreground and font."

And since copying a Graphics2D instance isn't very efficient (and
adversely affects Swing/Cairo performance), I tried to avoid the
create() call.  Note that prior to this change, Graphics2D was not used
at all (since all components returned a GtkImage in createImage()).

The right solution in this case would then be to improve
Graphics2D.create() performance by not copying the pixel buffer.  I can
look into this.

-- 
Ziga