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

[Sergey Bylokhov]

On 27.11.2013 15:12, Sergey Bylokhov wrote:
> 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.
Small additional notes, It would be good:
  - to wrap initial observer in the drawImage and replace img/x,y,.... 
in the observer.
  - don't draw hidpi image, if it was loaded with errors.
  - sun.com package should be used?
  - If MediaTracker was requested to load MultiResolutionImage,it should 
load all versions?
>
> 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.