[OpenJDK 2D-Dev] [PATCH] 4494651: Wrong width and height in BufferedImage GraphicsConfiguration objects

[Jim Graham]

Note that, per my previous email - this could easily be just closed as 
"not a bug", though it might be nice to change it so the bounds were 
completely unrelated to any specific image rather than randomly set to 
the first image that was queried.

In other words, I'd rewrite the bug synopsis as something like:

   GC reports random bounds (that happen to match first img)

and then hardcode some interesting bounds instead (perhaps the maximum 
supported image bounds - which we've never implemented or documented, 
but perhaps it would be a good way to introduce this concept for the 
future?)...

			...jim

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 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)..
> 
>   Thanks,
>     Dmitri
> 
> 
> Torsten Landschoff wrote:
>> Hello List,
>>
>> A few days before I ran into bug 4494651, after more than 7 years of 
>> its existence. See
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4494651
>>
>> I was curious how hard it would be to build a fixed OpenJDK, so I 
>> spent half of the saturday to get OpenJDK build and its unit tests 
>> running.
>>
>> Turned out that it wasn't that hard so here are my changes for you to 
>> consider.
>>
>> The first diff contains a trivial unit test derived from the example 
>> code in the bug log. The code should speak for itself.
>>
>> Tracing the bug to its origin, I found the interesting lookup table in 
>> BufferedImageGraphicsConfig.java which maps each imageType supported 
>> by BufferedImage to a BufferedImageGraphicsConfig. I have no idea why 
>> that would be a good idea (apart from performance), so the second diff 
>> just removes that feature and creates a new graphics configuration 
>> each time it is requested.
>>
>> As the only reason why one would create such a lookup table would be 
>> to get around performance problems, I wrote a third patch which caches 
>> the graphics configurations already retrieved in a weak hash map.
>>
>> Comments welcome. Feel free to apply my code to the OpenJDK code base, 
>> I'd be glad to sign the Sun Contributor Agreement if needed for such a 
>> trivial contribution.
>>
>>
>> Thanks for all your work, I really enjoy working with Java (and even 
>> more with its virtual machine and great libraries).
>>
>> Greetings, Torsten
>>