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

[Sergey Bylokhov]

Hello.
Probably we are in a point when it is necessary to stop and move out all 
extensions to the separate bugs.
We should give a time to our sqe to test these changes.
Actually current version looks good to me.

On 26.11.2013 2:31, Jim Graham wrote:
>
>
> On 11/25/13 5:51 AM, Alexander Scherbatiy wrote:
>> On 11/23/2013 5:11 AM, Jim Graham wrote:
>>> Hi Alexander,
>>>
>>> If we are going to be advertising it as something that developers use
>>> in production code then we would need to file this via CCC. With the
>>> current implementation, any user that has their own ImageObservers
>>> must use this API and so it becomes not only public, at a time when
>>> there is a lockdown on new public API in 8.0, but it also means that
>>> we are tied to its implementation and we can't rely on "it was
>>> experimental and so we can change it at any point" - you can't say
>>> that about an API that is necessary to correctly use a touted feature.
>>
>>      This issue has its own history.  It has been already fixed for the
>> JDK 7u for the Java2D demo. It was decided to not bring new API for the
>> HiDPI support in the JDK 7.
>>      It was suggested to using code like below to create a 
>> ScalableImage.
>> ------------------------------
>> /**
>>   * Class that loads and returns images according to
>>   * scale factor of graphic device
>>   *
>>   *  <pre> {@code
>>   *    Image image = new ScalableImage() {
>>   *
>>   *        public Image createScaledImage(float scaleFactor) {
>>   *            return (scaleFactor <= 1) ? loadImage("image.png")
>>   *                : loadImage("image at 2x.png");
>>   *        }
>>   *
>>   *        Image loadImage(String name){
>>   *            // load image
>>   *        }
>>   *    };}</pre>
>>   */
>> ------------------------------
>>
>>   It was based on the display scale factor. The scale factor should be
>> manually retrieved from the Graphics2D and was not a part of the public
>> API:
>>   g2d.drawImage(scalbleImage.getScaledImage(scaleFactor),..).
>>
>>   From that time it was clear that there should be 2 basic operations
>> for the HiDPI images support:
>>    - retrieve an image with necessary resolution
>>    - retrieve images with all resolutions
>>
>>    The second one is useful when it is necessary to create one set of
>> images using the given one (for example, to draw a shape on all images).
>
> For now, these are just ToolkitImages and you can't draw on them, so 
> this is moot for the case of @2x support in getImage().
>
>>    The JDK 7 solution has been revisited for the JDK 8 and the neccesary
>> CCC request 8011059  has been created and approved.
>>
>>    Both the JDK-8011059 issue description and the approved CCC request
>> says:
>>    -----------------------
>>    A user should have a unified way to provide high resolution images
>> that can be drawn on HIDPI displays according to the user provided
>> algorithm.
>>    -----------------------
>
> We've implemented the Hint part of that solution, but the mechanism 
> for creating custom multi-res images was not workable. I no longer sit 
> as the client rep on the CCC or I would have pointed that out, my 
> apologies.
>
>>    The 8011059 fix consists of two parts:
>>    - Provide a way for a custom image creation that holds images with
>> different resolutions
>>    - Load @2x images on Mac OS X
>>
>>    The first one of the fix can be used without the second. it is not
>> difficult to crate just a class which loads @2x images using the given
>> file path/url.
>
> If we support @2x transparently behind the scenes as we are doing now, 
> who is the requester for the way to create a custom set of resolution 
> variants?  I think the most important customer-driven request was to 
> support @2x for the Mac developers, wasn't it?
>
>>    Now it is suggested to implement the given MultiResolutionImage
>> interface  and override two methods:
>>     - Image getResolutionVariant(int width, int height)
>>     - List<Image> getResolutionVariants()
>>
>>     An image with necessary resolution should be drawn automatically in
>> SunGraphics2D.
>>
>>    What we need is to focus on the first part of the fix.
>>    From this point of view it up to the user' code to load all or some
>> resolution variants by MediaTracker and using
>> Component.prepareImage/checkImage methods.
>
> This is all an interesting goal, but I'm not sure it is as high a 
> priority if we support a convention (based on platform conventions) 
> for high resolution variants behind the scenes.  I do agree that we 
> need something like this before too long, but I don't think it was 
> workable to target the getScaledInstance() method as the mechanism to 
> implement it.  That was the only convention that was approved in that 
> CCC request, so a more complete API based on another mechanism is not 
> covered there.
>
> Also, Win8 has its own conventions as well which come into play on the 
> new high resolution Surface tablets and we should consider those to 
> guide the API we develop.
>
> All, in all, though, I think if we get @2x support in with no code 
> changes needed for apps then we have taken care of the primary use 
> case.  We can probably even handle the Win8 conventions behind the 
> scenes in an 8u release...
>
>             ...jim


-- 
Best regards, Sergey.