[OpenJDK 2D-Dev] <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame: support scaled painting

[Anton V. Tarasov]

[cc'ing to j2d]

On 12.12.2013 1:30, Jim Graham wrote:
>
>
> On 12/11/13 2:40 AM, Anton V. Tarasov wrote:
>> On 10.12.2013 23:57, Anthony Petrov wrote:
>>> I think that the image shouldn't be aware of any scale.
>>
>> The "scale" field put into the BufferedImage class means that an image
>> instance should (or shouldn't) be treated as a HiDPI image by the
>> Graphics.drawImage(). So, this is a kind of a special "scale" case,
>> aimed at supporting Retina technology. Probably it deserves a better
>> name, "hidpiScale" or something. So, it's not that the image has been
>> scaled by the user to be drawn on a lager area, but that the image
>> should (or shouldn't) be scaled just to "look smoothly" on a Retina
>> display. That's what I was thinking about...
>
> The problem with this, to me, is that a developer may make the assumption in layout that the image 
> will take "getWidth(null), getHeight(null)" size in the output when rendered with the default 
> "drawImage(img, x, y, obs)" call.  You are going to violate that assumption here.
>
> Another conflicting issue is that a developer would assume that if an image is "instanceof 
> BufferedImage" then those same dimensions are going to define how much data they can read when 
> they call getRGB(x, y) or get the raster.
>
> Something is going to break when trying to use buffered images for auto-scaled output.

Ok, there's another option, it's to return a layout size from getWidth/getHeight (as Anthony 
suggested). But this doesn't solve the problem with the raster and the backing array which will be 
of scaled length...

>
> Perhaps we need a "hidden image type based on buffered image internally" image to use in these 
> cases?  Or some sort of "render buffer object" which contains a reference to the image to render 
> into and a concept of the scale it will be rendered to and from rather than baking those concepts 
> directly into BufferedImage...?
>
> (Note that we already have this problem in FX as well when we introduced reading from images and 
> HiDPI in the same release, but we want the public object to return the layout sizes - for now we 
> average 4 pixels in the readback to solve the problem, but we do not expose the pixels like 
> BufferedImage and we are going to have to introduce API at some point to allow them to get a pixel 
> readback from a particular scaled version of the image...)
>
> If these images are not at all exposed to the developer in any way then I would encourage some 
> solution/mechanism that did not insert itself into BufferedImage.  Perhaps we could have SwingBI 
> class that extends BImg and introduces the scale factor at that level, only to be dealt with 
> internally?  Or does Swing have a bunch of "new BufferedImage()" calls sprinkled throughout?

Swing indirectly creates a BufferedImage via the factory methods: 
createCompatibleVolatileImage/createCompatibleImage/createImage. The question is if we can't export 
a scaled version of a BufferedImage, then what options do we have? What comes to my mind is this:

1) In every place such a method is called, call for a (internal private) "scaled version" of the method.
2) Somehow detect when the method is called by Swing and return a scaled BufferedImage or otherwise 
return a plain image. Not sure if a good solution exists.

Thanks,
Anton.

>
>             ...jim