<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi Sergey and Semyon,<br>
    <br>
    <div class="moz-cite-prefix">On 28/09/2017 19:49, Sergey Bylokhov
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:0ee0bd28-bf23-b726-97b4-8bbde57e65bc@oracle.com">On
      9/28/17 10:57, Semyon Sadetsky wrote:
      <br>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">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.
            <br>
          </blockquote>
          <br>
          The question what is the current screens resolution when you
          have two screens?
          <br>
        </blockquote>
        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.
        <br>
      </blockquote>
      <br>
      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.
      <br>
      <br>
      <blockquote type="cite">
        <blockquote type="cite">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.
          <br>
        </blockquote>
        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.
        <br>
      </blockquote>
      <br>
      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.
      <br>
      <br>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">For example one of the consumer of
              this new API is WindowsFileView.
              <br>
              How the code below should be changed to work on a
              different screens, and request the proper icon?
              <br>
              WindowsFileChooserUI.java
              <br>
              1316 icon =
              getFileChooser().getFileSystemView().getSystemIcon(f);
              <br>
            </blockquote>
            Why it should be changed? The code is requesting the proper
            icon.
            <br>
          </blockquote>
          <br>
          Because this method returns an icon of 16x16 pixels, which
          will be rescaled to 32x32 pixels in paint operation.
          <br>
        </blockquote>
        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.
        <br>
      </blockquote>
      <br>
      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.
      <br>
      <br>
      from the example above the code in WindowsFileChooserUI will use
      low-dpi icons on a HiDPI screen:
      <br>
      1316 icon = getFileChooser().getFileSystemView().getSystemIcon(f);
      <br>
      <br>
      How we should rewrite this code using a new API to support the
      icons which are large than default?
      <br>
    </blockquote>
    <br>
    If I understand correctly, the introduction of the new API does not
    change the behaviour in this case, does it?<br>
    <br>
    The icon extracted from Windows was 16×16 and will continue to be
    used.<br>
    That is the icon will be scaled when painted.<br>
    <br>
    To support HiDPI displays the implementation of <code>getFileChooser().getFileSystemView().getSystemIcon(f)</code>
    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, <code>IExtractIcon::Extract</code>
    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.)<br>
    <br>
    Different icon sizes could be combined into MRI lazily.<br>
    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.<br>
    <br>
    However, it looks to be out of the scope for this particular fix.
    Yet this approach will make UI look crispier at higher resolutions.<br>
    <br>
    <br>
    Regards,<br>
    Alexey<br>
  </body>
</html>