[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
