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

[Sergey Bylokhov]

On 07.11.2013 11:01, Jim Graham wrote:
> 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.
>
> 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.
That's not true we already do some kind of of new image creation inside 
DrawImage.makeBufferedImage() for example;
>
> 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.
I think no. They do not support.
>
> - 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.
That's why all related information: DPI,Scale, etc are not mentioned in 
the fix and api. just width and height are used, which is general and 
simple.
>
> - 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.
It is already in the current version of the fix.
>
> - (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.
It was intended to do not provide any mapping from some scale to the 
image, and leave it up to the user. So loading of the images will be 
lazily. Only if the image really needed it will be created and cached  
by the user.
>
> 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...
But we do not create any new API except two hints in Image and SG2D. 
Note that if compatibility is a problem from your point of view, we can 
control new hint in SG2D by some desktop property, and disable it by 
default. I think it can be useful to disable all hidpi support in this case.
>
>                 ...jim


-- 
Best regards, Sergey.