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

[Jim Graham]

On 12/12/13 2:33 PM, Sergey Bylokhov wrote:
> On 12/12/13 11:27 PM, Jim Graham wrote:
>> The only real difference here is that BufferedImages have multiple
>> definitions of width and height.  For VolatileImage objects there is
>> no view of the pixels so the dimensions are the layout size and the
>> expected renderable area and the returned graphics is pre-scaled.  For
>> BufferedImage we can do all of that, but the dimensions have the added
>> implication that they define the valid range of values for getRGB(x,
>> y) and grabbing the rasters/data buffers/arrays and digging out pixels
>> manually.
>>
>> If it were just getRGB(x, y) we could simply do a 2x2 average of
>> underlying pixels to return an RGB value, but I don't think there is
>> any amount of workaround that we can apply to make the digging out of
>> the rasters and storage arrays work for those who manually access
>> pixels...  :(
> But I am talking about OffScreenImage(or we can add new one), which is
> not public so we can try to block/change operations in our code. Not
> sure that our backbuffers leaked to the users.

OffscreenImage is a subclass of BufferedImage so if a developer ever 
gets their hands on it then they may get confused by our use of the 
getWidth/Height.  But, if there is no way for them to get a reference to 
it, then we can play games internally.

This will not help us with the return value of getCompatibleImage(), 
though, which is specified to return a BufferedImage so we are somewhat 
restricted in any use of logical dimensions there.

Also, if we are entirely managing the buffer internally, then we have 
the option to just use a regular BufferedImage.  We don't need any extra 
magic if we render it with drawImage(x, y, w, h) since the "logical" or 
"real" dimensions of the image have no impact on the results there.  If 
it is double-sized then those pixels will fit into the appropriate space 
on the destination without any need to special case them in SG2D...

				...jim