<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    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>
    <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>
  </body>
</html>