Hi Alexander,
Before we get too far down the road on this API, I think we understand
the way in which MacOS processes multi-resolution images for HiDPI
screens, but have we investigated the processes that Windows uses under
Windows 8? My impression is that Windows 8 has included a number of new
techniques for dealing with the high resolution displays that it will
run on in the Windows tablet and mobile industries and that these will
also come into play as 4K displays (already available) become more
common on the desktop. We should make sure that what we come up with
here can provide native compatibility with either platform's policies
and standard practices.
If you've investigated the MS policies I'd like to see a summary so that
we can consider them as we review this API...
...jim
On 1/14/14 2:54 AM, Alexander Scherbatiy wrote:
Hello,
Could you review the fix:
bug: https://bugs.openjdk.java.net/browse/JDK-8029339
webrev: http://cr.openjdk.java.net/~alexsch/8029339/webrev.00
This is a proposal to introduce an API that allows to create a custom
multi resolution image.
I. It seems reasonable that the API should provide two basic operations:
1. Get the resolution variant based on the requested image width and
height:
- Image getResolutionVariant(int width, int height)
Usually the system provides the scale factor which represents the
number of pixels corresponding to each linear unit on the display.
However, it has sense to combine the scale factor and the current
transformations to get the actual image size to be displayed.
2. Get all provided resolution variants:
- List<Image> getResolutionVariants()
There are several uses cases:
- Create a new multi-resolution image based on the given
multi-resolution image.
- Pass to the native system the multi-resolution image. For example,
a use can set to the system the custom multi-resolution cursor.
II. There are some possible ways where the new API can be added
1. java.awt.Image.
The 2 new methods can be added to the Image class. A user can override
the getResolutionVariant() and getResolutionVariants() methods to
provide the resolution variants
or there can be default implementations of these methods if a user
puts resolution variants
to the list in the sorted order.
To check that the image has resolution variants the following
statement can be used: image.getResolutionVariants().size() != 1
The disadvantage is that there is an overhead that the Image class
should contain the List object and not all
images can have resolution variants.
2. Introduce new MultiResolutionImage interface.
A user should extend Image class and implement the
MultiResolutionImage interface.
For example:
---------------------
public class CustomMultiResolutionImage extends BufferedImage
implements MultiResolutionImage {
Image highResolutionImage;
public CustomMultiResolutionImage(BufferedImage baseImage,
BufferedImage highResolutionImage) {
super(baseImage.getWidth(), baseImage.getHeight(),
baseImage.getType());
this.highResolutionImage = highResolutionImage;
Graphics g = getGraphics();
g.drawImage(baseImage, 0, 0, null);
g.dispose();
}
@Override
public Image getResolutionVariant(int width, int height) {
return ((width <= getWidth() && height <= getHeight()))
? this : highResolutionImage;
}
@Override
public List<Image> getResolutionVariants() {
return Arrays.asList(this, highResolutionImage);
}
}
---------------------
The current fix adds the MultiResolutionImage interface and public
resolution variant rendering hints.
Thanks,
Alexandr.
