<AWT Dev> [9] Review request for 8029339 Custom MultiResolution image support on HiDPI displays

Alexander Scherbatiy alexandr.scherbatiy at oracle.com
Wed Feb 12 05:59:26 PST 2014

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


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

More information about the awt-dev mailing list