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

[Jim Graham]

On 2/10/14 6:11 AM, Anton V. Tarasov wrote:
>> 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.

It might make sense to leave it in for now.  I'm not happy with that 
design conceptually in the long term, but I don't think there is a 100% 
pure/simple/obvious solution to the issues we are facing and it's not 
really hurting anything in the short term...

			...jim