Hi Sergey and Semyon,
On 28/09/2017 19:49, Sergey Bylokhov wrote:
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 screens?
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 as is.
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?
WindowsFileChooserUI.java
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?
If I understand correctly, the introduction of the new API does not
change the behaviour in this case, does it?
The icon extracted from Windows was 16×16 and will continue to be used.
That is the icon will be scaled when painted.
To support HiDPI displays the implementation of
|getFileChooser().getFileSystemView().getSystemIcon(f)| should be
enhanced to fetch the icon at the appropriate size according to the
current rendering scale. I mean in standard resolution, get 16×16 icon,
for 125% scale factor, get 20×20 icon, for 150% scale factor, get icon
24×24. (As far as I know, |IExtractIcon::Extract| does not perform any
scaling to account for HiDPI rendering. And it really can't because
different displays can have different DPI settings. Thus if you request
icon size of 16×16, you'll get 16×16 icon, not 32×32 even if this size
is more appropriate to the current HiDPI scaling.)
Different icon sizes could be combined into MRI lazily.
To support it, we could use different APIs to extract the icons. For
example, we can get the list of icon sizes for a file type, and extract
only “native” size. If larger size is required for HiDPI and the icon
has it, then get the larger version and use it for rendering rather than
scaling the one we already have.
However, it looks to be out of the scope for this particular fix. Yet
this approach will make UI look crispier at higher resolutions.
Regards,
Alexey
