Hi Dmitri, On Tue, Feb 17, 2009 at 06:13:47PM -0800, Dmitri Trembovetski wrote: > > Note that this fix may have some performance > implications for cases when there are caches based on the > graphics configuration of the Graphics object used for > rendering - these caches may grow uncontrollably.
I don't see how this could happen with either of my patches: a) The trivial approach will create a new GraphicsConfiguration instance on each call to Graphics2D#getDeviceConfiguration. Which I would expect as the JavaDoc states that it "Returns the device configuration associated with this Graphics2D.". Reference: http://java.sun.com/javase/6/docs/api/java/awt/Graphics2D.html#getDeviceConfiguration() b) My second patch uses a WeakHashMap to cache the already retrieved graphics configuration instances. I would expect it to be faster for very few instances cached and slower when many instances are cached. So I don't think it's worth the effort. Anyway, assuming that the WeakHashMap will clean up left-over keys, this implementation should keep at most as many graphics configuration instances as there are Graphics2D instances referring to BufferedImages, for which getDeviceConfiguration was called. What am I missing? > I don't know of any other solution for this bug, but I'm > not sure fixing it would do more harm than good. > The bug has only 3 votes after 8 years (all of them > in 2001-2002).. Is it better to leave a known bug unfixed for fears of performance regressions? While this bug goes unnoticed for long time, actually finding it (even though it is recorded) can consume a lot of developer time. Greetings, Torsten
