[OpenJDK 2D-Dev] <AWT Dev>  Review Request: JDK-8029455 JLightweightFrame: support scaled painting
Anton V. Tarasov
anton.tarasov at oracle.com
Mon Feb 3 14:36:48 UTC 2014
Please look at the updated version:
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
- 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
More information about the 2d-dev