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.
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
that need...
...jim
