On 2/8/2014 4:19 AM, Jim Graham wrote:
The primary thing that I was concerned about was the presence of
integers in the API when Windows uses non-integer multiples
It would make sense to pass real numbers to the
getResolutionVariant() method if the difference between resolution
variants sizes is 1.
It seems that it is not a common case.
and also what policy they use for choosing scaled images.
I don't see a mention of taking the current transform into account,
just physical issues like screen DPI and form factor. They talk about
resolution plateaus and in their recommendations section they tell the
developer to use a particular property that tells them the screen
resolution to figure out which image to load if they are loading
manually. There is no discussion about dynamically loading multiple
versions of the image based on a dynamic program-applied transform
factor as is done on MacOS.
Also, they tell developers to draw images to a specific size rather
than using auto-sizing. That begs the question as to how they
interpret a call to draw an image just using a location in the
presence of various DPI factors.
There is an interesting doc that describes how to write DPI-aware
Win32 applications:
http://msdn.microsoft.com/en-us/library/dd464646%28v=vs.85%29.aspx
It is suggested to handle WM_DPICHANGED message, load the graphic
that has slightly greater resolution to the current DPI and use StretchBlt
to scale down the image.
Thanks,
Alexandr.
...jim
On 2/7/14 3:00 AM, Alexander Scherbatiy wrote:
On 1/22/2014 6:40 AM, Jim Graham wrote:
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...
There is the Windows Guidelines for scaling to pixel density:
http://msdn.microsoft.com/en-us/library/windows/apps/hh465362.aspx
which says that Windows has automatic resource loading that supports
three version of images scaling (100%, 140%, and 180%)
--------------------------------
Without scaling, as the pixel density of a display device increases, the
physical sizes of objects on screen get smaller.
When UI would otherwise be too small to touch and when text gets too
small to read,
Windows scales the system and app UI to one of the following scaling
plateaus:
1.0 (100%, no scaling is applied)
1.4 (140% scaling)
1.8 (180% scaling)
Windows determines which scaling plateau to use based on the physical
screen size, the screen resolution, the DPI of the screen, and form
factor.
Use resource loading for bitmap images in the app package For bitmap
images stored
in the app package, provide a separate image for each scaling
factor(100%, 140%, and 180%),
and name your image files using the "scale" naming convention described
below.
Windows loads the right image for the current scale automatically.
--------------------------------
The image name convention for the various scales is:
images/logo.scale-100.png
images/logo.scale-140.png
images/logo.scale-180.png
The 'ms-appx:///images/logo.png' uri is used to load the image in an
application.
If we want to support this in the same way as it is done for Mac OS X
the WToolkit should return MultiResolution image in case if the
loaded image has .scale-* qualifiers.
The Graphics class can request an image with necessary resolution
from the MultiResolution image.
It seems that nothing should be changed in the MultiResolution
interface in this case.
Thanks,
Alexandr.
...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.
