<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    > The method getImageUsingNamingSchemes(String fileName,
    MediaResolutionNamingScheme... <br>
    >  namingSchemes) works for any scheme not only for the default
    one.<br>
    <br>
    I'm sure it does. My point is that we don't need it.<br>
    No one will care or use it. They just want to list their image
    files.<br>
    <br>
    The naming scheme is only important for the cases when people<br>
    are NOT supplying an explicit list of images to getImage.<br>
    So public API for the naming schema - or the float scale - is
    completely unnecessary<br>
    bloat and complication.<br>
    <br>
    -phil.<br>
    <br>
    On 9/22/16, 10:23 AM, Alexandr Scherbatiy wrote:
    <blockquote
      cite="mid:882990fb-1858-e2b2-f282-9aaf60c666ad@oracle.com"
      type="cite">
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
      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>
    </blockquote>
  </body>
</html>