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 _______________________________________________ Classpath-patches mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath-patches
