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

[Anton V. Tarasov]

Hi Jim!

On 08.02.2014 4:56, Jim Graham wrote:
> Hi Anton,
>
> In CPlatformLWWindow.java, why does it have to search for the right device when it was created 
> with/from a Window object that should already know the right device?

As I wrote before, JLF doesn't have any platform window behind (it's a trully lightweight frame). 
That's why we can't simply get an associated device and need some heuristic...

>
> SG2D, line 2114 - I think TRANSFORM_SCALE allows negative scale factors so I think you need a 
> little more protection from the transform call reversing the rectangle.

Ok, I'll elaborate on it.

>
> Otherwise, I didn't spot any other issues...

Glad to hear that :)

>
> On 2/3/14 6:36 AM, Anton V. Tarasov wrote:
>> 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.
>
> Would we expect one of these images to have the BufferedImageOp version of drawImage be used on 
> it?  (It could happen if we ever leak the object into developers hands, but I'm not sure if that 
> can happen or not - I'm pretty sure we don't use those Ops internally ourselves, do we?)

We don't use it internally. Originally, I had an option in the fix with which a developer could 
create a HiDPI BufferedImage. Then, I implemented the last SG2D.drawImage method which didn't have 
hidpi support, and created a 2D test for it. In the test I drew some 2D primitives into a HiDPI 
image, using a BufferedImageOp transform. So, I just tested the ability to use it externally.

In the current version of the fix there's no option to get a HiDPI image from the outside, so this 
code is not really used. I can eliminate it if we think we don't need it in the nearest future.

Thanks,
Anton.

>
>             ...jim