<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:
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.
>>>>
>>
More information about the awt-dev
mailing list