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

[Jim Graham]

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