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

[Anton V. Tarasov]

Summarizing your comments. We can't export a scaled version of a 
BufferedImage in the bounds of the current API without violating the 
spec. Unless a scaled BufferedImage is used internally, in which case we 
are less constrained. Ok, let's try this approach. I searched the code 
for all the cases of calling those factory methods I mentioned which 
create (or may create) a BufferedImage: Component.createImage(..), 
GraphicsConfiguration.createCompatibleImage(..), 
GraphicsConfiguration.createCompatibleVolatileImage(..). I found 19 
cases, but only 3 of them matters (the cases in which JLF differs from 
standalone Swing). These are double buffers creation in JViewport and 
RepaintManager, and AbstractRegionPainter.getImage(). Plus 1 case when 
we create a root BufferedImage directly from JLightweightFrame. It's 
possible to replace them with internal versions of the factory methods 
which will return a scaled BufferedImage.

Then, the suggestion to return layout bounds from a scaled 
BufferedImage, and physical bounds from its BufImgSurfaceData (we don't 
bother about getRGB for now) eliminates the need to translate to layout 
bounds in SG2D and unifies the code.

So, I'm going this way...

Thanks,
Anton.

On 12/13/13 2:54 AM, Jim Graham wrote:
>
>
> 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