On 07.11.2013 11:01, Jim Graham wrote:
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.
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.
That's not true we already do some kind of of new image creation inside
DrawImage.makeBufferedImage() for example;
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.
I think no. They do not support.
- 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.
That's why all related information: DPI,Scale, etc are not mentioned in
the fix and api. just width and height are used, which is general and
simple.
- 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.
It is already in the current version of the fix.
- (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.
It was intended to do not provide any mapping from some scale to the
image, and leave it up to the user. So loading of the images will be
lazily. Only if the image really needed it will be created and cached
by the user.
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...
But we do not create any new API except two hints in Image and SG2D.
Note that if compatibility is a problem from your point of view, we can
control new hint in SG2D by some desktop property, and disable it by
default. I think it can be useful to disable all hidpi support in this case.
...jim
--
Best regards, Sergey.
