[OpenJDK 2D-Dev] [9] Review request for 8029339 Custom MultiResolution image support on HiDPI displays

Alexander Scherbatiy alexandr.scherbatiy at oracle.com
Fri Feb 7 11:00:59 UTC 2014


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.
>>




More information about the 2d-dev mailing list