<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 9/21/2016 9:47 PM, Philip Race wrote:<br>
    <blockquote cite="mid:57E2D5D6.1070004@oracle.com" type="cite">
      <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
      Hi,<br>
      <br>
      When the application is specifying the set of images from which<br>
      to build the MRI you ask the app to specify a "schema" (probably
      not the<br>
      right name given that it is per-file), and a floating point scale.<br>
      <br>
      I don't see why we need to ask the app to name the files<br>
      in accordance with our schema in this case .. it should just be<br>
      able to list the set of files. It looks redundant to an app
      developer<br>
      to say "150pct" is scale "1.5".<br>
    </blockquote>
    <br>
       The method getImageUsingNamingSchemes(String fileName,
    MediaResolutionNamingScheme... namingSchemes) works for any scheme
    not only for the default one.<br>
       For example call <br>
       Image image = toolkit.getImageUsingNamingSchemes(url,<br>
               new Toolkit.MediaResolutionNamingScheme("-144dpi", 1.5f),<br>
               new Toolkit.MediaResolutionNamingScheme("-192dpi", 2f)<br>
       );<br>
       loads resolution variants image-144dpi.png and image-192dpi.png
    for the base image.png image.<br>
     <br>
       If it is necessary I can add a method like
    Toolkit.loadImageWithScales(String fileName, float... scales) which
    loads resolution variants for the given scales using the default
    scheme.<br>
    <br>
      Thanks,<br>
      Alexandr.<br>
    <blockquote cite="mid:57E2D5D6.1070004@oracle.com" type="cite"> <br>
      Obviously the ideal is the image is exactly what the naming
      convention<br>
      implies it is, but what if it is not ?<br>
      <br>
      This issue does exist already even in JDK 8 .. if the<br>
      @2x image is really 1.5X the @1 image<br>
      <br>
      Consider what happens if this contradicts the floating point scale
      ?<br>
      It appears to me that as implemented, in practice, the app could
      call it "@XXX",<br>
      and once @XXX has been used to find the file, the only thing that
      actually<br>
      matters is the floating point scale.<br>
      <br>
      So the naming schema is not important when they provide the scale.<br>
      <br>
      But we still have the issue that the *actual* image size may not
      be<br>
      what they said it was  - either explicitly or by convention.<br>
      <br>
      Supposing what is claimed to be a 1.5x1.5 scale image is actually<br>
      1.0x2.0 times the size of the base image ? It is not even uniform.<br>
      <br>
      Ultimately what needs to "win" is the w:h ratio of the base image<br>
      and we generally would want to pick whichever image best works<br>
      for the actual device scale, based on the *real* dimensions of<br>
      the hi-res image, don't we ?<br>
      <br>
      In which case, I'd expect us to work out the scale automatically.<br>
      It is WID_HIRES/WID_BASE x HGT_HIRES/HGT_BASE<br>
      <br>
      At which point why do we even need the app to tell us anything<br>
      except the (full) names of the files where to get the set of
      images,<br>
      with the first one being the base .. or perhaps it should always<br>
      be the "smallest".<br>
      <br>
      Otherwise if any are in fact smaller (or the same as) BASE .. do
      we just discard them ?<br>
      <br>
      -phil.<br>
      <br>
      On 9/19/16, 12:03 PM, Alexander Scherbatiy wrote:
      <blockquote
        cite="mid:95393580-c8c7-9954-b499-040ada327eaa@oracle.com"
        type="cite">
        <meta content="text/html; charset=utf-8"
          http-equiv="Content-Type">
        Hello,<br>
        <br>
        Could you review the updated fix:<br>
          <a moz-do-not-send="true" class="moz-txt-link-freetext"
          href="http://cr.openjdk.java.net/%7Ealexsch/8163854/webrev.01">http://cr.openjdk.java.net/~alexsch/8163854/webrev.01</a><br>
        <br>
        The fix includes support for resolution variants loading by
        getImage() method for built-in toolkits using the following
        media resolution naming scheme (qualifier, scale): ("@125pct",
        1.25), ("@150pct", 1.5), ("@200pct" or "@2x", 2), ("@250pct",
        2.5), ("@300pct" or "@3x", 3).<br>
         <br>
        Thanks,<br>
        Alexandr.<br>
        <br>
        <div class="moz-cite-prefix">On 25/08/16 05:39, Philip Race
          wrote:<br>
        </div>
        <blockquote cite="mid:57BE4C6F.6030007@oracle.com" type="cite">FWIW
          I think the most important image loading use case <br>
          is that some generic resource loading code - perhaps JDK code
          - will get a URL for where <br>
          the resources are and go hunting. It is never going to call
          this API .. so <br>
          it had better be an optimisation and not a necessity <br>
          <br>
          -phil. <br>
          <br>
          <br>
          On 8/24/16, 5:24 PM, Philip Race wrote: <br>
          <blockquote type="cite">Alexander, <br>
            <br>
            Were  the existing Toolkit.getImage(String/URL) APIs not
            enhanced to <br>
            do this for you automatically ? I suppose I thought they
            were but <br>
            they can't be since you are using getImage(String) here. <br>
            <br>
            IMO that would be more important than this. <br>
            <br>
            And in any case I don't see why this is solved only for
            local files. <br>
            <br>
            I am *not* asking for that right now. I am asking if the
            existing Toolkit APIs <br>
            can load a multi-res image and if not, why not  and can we
            fix that instead .. <br>
            <br>
            -phil. <br>
            <br>
            On 8/24/16, 9:36 AM, Alexander Scherbatiy wrote: <br>
            <blockquote type="cite"> <br>
              Hello, <br>
              <br>
              Could you review the fix: <br>
                bug: <a moz-do-not-send="true"
                class="moz-txt-link-freetext"
                href="https://bugs.openjdk.java.net/browse/JDK-8163854">https://bugs.openjdk.java.net/browse/JDK-8163854</a>
              <br>
                webrev: <a moz-do-not-send="true"
                class="moz-txt-link-freetext"
                href="http://cr.openjdk.java.net/%7Ealexsch/8163854/webrev.00">http://cr.openjdk.java.net/~alexsch/8163854/webrev.00</a>
              <br>
              <br>
                The public API which allows to load an image with
              resolution variants based on the provided media resolution
              naming scheme is added: <br>
                - Toolkit.MediaResolutionNamingScheme class <br>
                - Toolkit.getImageUsingNamingSchemes(String fileName,
              MediaResolutionNamingScheme... namingSchemes) <br>
              <br>
                A simple example for images which use naming scheme
              @150pct for scale 1.5 and @2x for scale 2 is: <br>
                  image_name.ext <br>
                  <a moz-do-not-send="true"
                class="moz-txt-link-abbreviated"
                href="mailto:image_name@150pct.ext">image_name@150pct.ext</a>
              <br>
                  <a moz-do-not-send="true"
                class="moz-txt-link-abbreviated"
                href="mailto:image_name@2x.ext">image_name@2x.ext</a> <br>
              <br>
                  Toolkit toolkit = Toolkit.getDefaultToolkit(); <br>
                  Image image =
              toolkit.getImageUsingNamingSchemes(fileName, <br>
                          new
              Toolkit.MediaResolutionNamingScheme(“@150pct”, 1.5f), <br>
                          new Toolkit.MediaResolutionNamingScheme(“@2x",
              2f) <br>
                  ); <br>
              <br>
                Thanks, <br>
                Alexandr. <br>
              <br>
            </blockquote>
          </blockquote>
        </blockquote>
        <br>
      </blockquote>
    </blockquote>
    <br>
  </body>
</html>