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

[Jim Graham]

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.

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?

			...jim