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

[Torsten Landschoff]

Hi Jim, 

On Tue, Feb 17, 2009 at 06:27:43PM -0800, Jim Graham wrote:
> The width and height of a GraphicsConfig is essentially irrelevant  
> information.  If you get the GraphicsConfig of a component, it doesn't  

Why is there a method then to query irrelevant information?

> tell you how big that component was, so why should the GC of a BufImg  
> bear any relation to the dimensions of the image?

Why would the graphics configuration contain the size of the component?
Quoting the docs: "The GraphicsConfiguration class describes the
characteristics of a graphics destination such as a printer or monitor."
Therefore I would expect the bounds to match the size of the screen 
I am painting to, not the size of the component.

The use case for me was to fix a drawing routine which made two passes 
over the input data to have the second pass paint over the first. This 
turned out to be quite slow with the main time going into loading the 
data. So I optimized it to paint in one pass, by using a BufferedImage 
to paint the overlay data and merge it later. The only object that 
could give me the size of the output Graphics device was - surprise -
the Graphics2D instance.

This works fine when drawing directly to the screen, but unfortunately 
not when double buffering is used. I think this is a very valid use case.

> If anything, I'd fix it by having it report some fixed bogus (positive,  
> large) dimensions rather than the dimensions of the first image that it  
> was created from...

Why? Code calling it will only fall over with that, perhaps even worse 
than the status quo when expecting valid values. 

Using negative dimensions for example would clearly mark the data as 
invalid, but in my case would lead to IllegalArgumentException in the
BufferedImage constructor (as I take the sizes at face value).

If you really want to disable usable functionality in an update to the
JDK, I'd suggest to use UnsupportedOperationException so that the
caller at least knows what is going on.

Anyway, I don't understand the fuss about such a simple code change. 
Maybe it will eat some cycles and a bit of memory, but there is not 
even a comment in the original BufferedImageGraphicsConfig code why 
that hack there is really needed. 


I find it curious that all but the indexed image type configurations 
are cached and it seems not be a problem there:

47 private static final int numconfigs = BufferedImage.TYPE_BYTE_BINARY;
==> the highest image type is     public static final int TYPE_BYTE_INDEXED = 13;

48 private static BufferedImageGraphicsConfig configs[] =
49 new BufferedImageGraphicsConfig[numconfigs];
50
51 public static BufferedImageGraphicsConfig getConfig(BufferedImage bImg) {
52 BufferedImageGraphicsConfig ret;
53 int type = bImg.getType();
54 if (type > 0 && type < numconfigs) {
55 ret = configs[type];
56 if (ret != null) { 




On Tue, Feb 17, 2009 at 06:30:36PM -0800, Jim Graham wrote:
> 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.

The Java API docs state that getBounds() will return the bounds in device 
coordinates. You say that information is irrelevant, so it is not a bug? 
What value do the API docs have then?


> 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?)...

I think that would be a slippery slope as this could depend on the amount of 
virtual memory - which is hard to measure, and even then nobody would like 
to have the crawling speed.



On Tue, Feb 17, 2009 at 06:39:44PM -0800, Jim Graham wrote:
> In fact, I've just updated the synopsis and evaluated the bug along  
> these lines... ;-)

Where can I read the updated bug entry? The URL known to me is 

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4494651

and its content did not change (apart from some CSS hickups the last
few days).


Greetings, Torsten