<AWT Dev> <Swing Dev>  Review request for 8182043: Access to Windows Large Icons
Sergey.Bylokhov at oracle.com
Thu Sep 28 18:49:22 UTC 2017
On 9/28/17 10:57, Semyon Sadetsky wrote:
>>> Small and large don't have any special meanings for HiDPI. They are
>>> some conditional sizes established by the native platform for the
>>> current screen resolution.
>> The question what is the current screens resolution when you have two
> We should relay on the native platform always. So, the icon size
> returned by the native API is the correct approach. And possibility to
> use any other sizes is provided as well.
On windows and Linux we cannot rely on the native system because all
HiDPI support is implemented on our(jdk) side, the native system does
not know how this icons are used.
>> It is half of the correct size because on HiDPI it is better to use
>> hidpi icons instead of lowdpi. Will the HiDPI unaware apps draw x2
>> icons correctly or not depends from our implementation. If we will
>> return the MRI then it will be drawn in correct size even if the
>> bigger(HiDPI) image will be used.
> This is not true. MRI has a basic size which uniquely determines its
> painted size in component coordinates. The size painted in component
> will be the same for all scales this is how HiDPI works in java.
The size in a component coordinates will be the same, but if HiDPI image
is used the real number of pixels to be drawn will be 4 times bigger,
because low-dpi images will be scaled x2 and HiDPI images will be drawn
>>>> For example one of the consumer of this new API is WindowsFileView.
>>>> How the code below should be changed to work on a different screens,
>>>> and request the proper icon?
>>>> 1316 icon = getFileChooser().getFileSystemView().getSystemIcon(f);
>>> Why it should be changed? The code is requesting the proper icon.
>> Because this method returns an icon of 16x16 pixels, which will be
>> rescaled to 32x32 pixels in paint operation.
> The size should be equal 16x16 otherwise the component view will be
> distorted. But painted resolution is determined by native platform. The
> native platform may return icon of any size. If the size of the icon
> differs from 16x16 (32x32 for example) then it will be wrapped by MRI of
> 16x16 size.
The draw resolution cannot be calculated by the native platform for each
window in java. The windows provide a set of icons for each resolution,
and we should select correct one depending from the scalefactor of our
window. And we should draw bigger icons when the bigger dpi is in use.
from the example above the code in WindowsFileChooserUI will use low-dpi
icons on a HiDPI screen:
1316 icon = getFileChooser().getFileSystemView().getSystemIcon(f);
How we should rewrite this code using a new API to support the icons
which are large than default?
Best regards, Sergey.
More information about the awt-dev