<AWT Dev> [OpenJDK 2D-Dev]  Review request for 8011059 [macosx] Make JDK demos look perfect on retina displays
james.graham at oracle.com
Wed Nov 6 23:01:33 PST 2013
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:
>> 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
More information about the awt-dev