<AWT Dev> [OpenJDK 2D-Dev] [8] Review request for 8011059 [macosx] Make JDK demos look perfect on retina displays

[Jim Graham]

On 11/6/13 6:15 PM, Sergey Bylokhov wrote:
>>> In this example there is a problem. For example we have 2
>>> BufferedImages/ToolkiImagest A and B; Both wants be scaled perfectly.
>>>   - Image A draws to the image B
>>>   - Image B draws to the window.
>>>
>>> When window is moving from the screen x1 to the screen x2 and back. How
>>> to handle this situation?
>>> In this case getResolutionVariant() can return
>>>
>>>
>>> Related  discussion:
>>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005580.html
>>>
>>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005581.html
>>>
>>
>> How does calling getScaledInstance() deal with that?  Note the above
>> was simply to demonstrate the visibility of the interface, not to be a
>> complete implementation...
> For example:
>   - getScaledInstance() will be called() when image B will be painted to
> the window with scale x2.
>   - Inside B.getScaledInstance() the user can create BufferedImage C
>   - get graphics from C and set new render hint to IMAGE_SCALING_ON ans
> set scalex2.
>   - Apply to C absolutely the same rendering  which was used in B.
>   - getScaledInstance() will be called for A.

That is a radical departure from anything we've provided before and I 
don't see the necessity of it.

In particular, drawImage() has always been a "copy some pixels and 
return *now*" API.  Even when we had asynchronous loading of images it 
returned immediately if the image wasn't loaded, it didn't fork off or 
branch to another rendering process.  I really don't think we should be 
encouraging creating a new image inside a request to draw an image.

Nothing in those related discussions pointed at this either.  What I see 
the need for is:

- Toolkit images automatically supporting loading an @2x image if one is 
associated with the image they are requested to load.  I think they 
already do this and you just need a way for drawImage() to grab that 
image if necessary.

- All images to have an associated resolution or pixel scale.  @2x 
variants of images, if we ever expose them directly, would claim either 
a pixel scale of 2 or a DPI of ?144?, i.e. double the implicit dpi of 72 
that most images claim or that we've assumed by default.

- Destination drawables having a resolution or pixel scaling parameter 
associated with them that lets G2D decide if it is going to use hiDPI 
media or not.  It would request a HiDPI version of an image if needed, 
but this should be a simple "choose this set of pixels or that set" API, 
not an "I'll make you one right now" type of API.

- (not necessarily now, but soon) A way for someone to associate a 
higher DPI version of an image with an existing image and to query any 
alternate resolutions that we've already prepared (such as any @2x 
version that we've already loaded).  This could either be 
"Image.createMultiResImage(... list of images and resolutions ...)" or 
perhaps a convention for listing alternate images in the properties.

As far as the "images for buttons" example in the macosx-port thread, if 
those images are loaded using Toolkit.getImage() and there is an 
associated @2x image and we load that internally and make it available 
via some sort of (internal for now) MultiResImage interface like I 
described, then we've solved that problem for buttons.  It seemed like 
that was all that they were asking for there and I see no reason to 
create a "solve every hypothetical resolution issue" API now to meet 
that need...

				...jim