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

[Sergey Bylokhov]

Hi, Anton.
Please check performance w/o buffers too, to know the difference.

On 13.12.2013 22:13, Anton V. Tarasov wrote:
> 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
>


-- 
Best regards, Sergey.