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

[Anton V. Tarasov]

Hi Jim,

Please look at the updated version:

http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.4

On 01.02.2014 5:35, Jim Graham wrote:
> Hi Anton,
>
> On 1/31/14 6:37 AM, Anton V. Tarasov wrote:
>> My understanding is that, unless the fix is absolutely irrelevant (whic
>> I hope it isn't), we should integrate it into 9/8u20 to support
>> SwingNode in its current implementation on Retina displays.
>>
>> What do you think?
>
> I agree with this sentiment.  My suggestion for reducing its footprint aside (which it looks like 
> you are investigating), the main thing I will be looking for is whether or not we return an object 
> to a developer (i.e. it isn't just managed internally to our own code) where they can do 
> "instanceof BufferedImage" and then see something odd coming from its width/height.
>
> It looks like if we simply use getLayoutWH() internally then they would never ever see anything 
> odd from getWidthHeight() anyway. The only additional "gotcha" would be if they grab the image and 
> render it directly and it comes out an unexpected size to them (because, for instance, they didn't 
> check the layout dims like we do internally). That's a pretty minor issue, though, and I think we 
> could live with it.

I've refactored the fix with this concern in mind. Here is what I've done:

- eliminated the new OffscreenHiDPIImage class (as you suggested) and put all of its "scale" logic 
into the OffscreenImage.
- made the scaled OffscreenImage return the physical size (like an ordinary BufferredImage does) by 
default .
- renamed the "set/isHiDPIEnabled" method to "set/isReturnLayoutSize".
- made the setReturnLayoutSize(true) be called internally (where we don't leak the OffscreenImage).

In SG2D, the drawHiDPIImage, for instance, makes a call to op.filter(img, null); where the img is 
expected to return its layout size. That's why I still prefer to use the setReturnLayoutSize 
"switcher", in order not to go deep into the 2D rendering code, casting here and there to 
OffscreenImage and calling getLayoutWidth/Height.

>
> For 9.0 perhaps we could add the LayoutWH() as new API on BufferedImage and then most of this 
> would be public?  I'd have to mull over if that makes sense and I'm not entirely sure of the 
> naming yet...

That's a good idea, however we need a 8u working solution as well... As to the naming, I'm ready for 
any suggestions.

Thanks,
Anton.

>
>             ...jim