<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Also as I pointed out before a string specified per-variant is not a
    naming  *scheme*.<br>
    It is just a "per-file" add-on to the basename<br>
    <br>
    I could use<br>
    Image image = toolkit.getImageUsingNamingSchemes(url,<br>
               new Toolkit.MediaResolutionNamingScheme("abc", 1.5f),<br>
               new Toolkit.MediaResolutionNamingScheme("foo", 2f)<br>
    <br>
    to load files "img.png", "imgabc.png", and "imgfoo.png"<br>
    That doesn't look like a consistent scheme at all ...<br>
    so give up on that and just have them list the full names and<br>
    get rid of the unneeded API.<br>
    <br>
    -phil.<br>
    <br>
    On 9/22/16, 10:56 AM, Philip Race wrote:
    <blockquote cite="mid:57E41B4F.5080900@oracle.com" type="cite">
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
      > 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>
    </blockquote>
  </body>
</html>