[OpenJDK 2D-Dev] [9] Review request for 8163854 Add ToolkitImage.getImage() method which loads an image with schema variant

[Alexandr Scherbatiy]

On 9/21/2016 9:47 PM, Philip Race wrote:
> Hi,
>
> When the application is specifying the set of images from which
> to build the MRI you ask the app to specify a "schema" (probably not the
> right name given that it is per-file), and a floating point scale.
>
> I don't see why we need to ask the app to name the files
> in accordance with our schema in this case .. it should just be
> able to list the set of files. It looks redundant to an app developer
> to say "150pct" is scale "1.5".

    The method getImageUsingNamingSchemes(String fileName, 
MediaResolutionNamingScheme... namingSchemes) works for any scheme not 
only for the default one.
    For example call
    Image image = toolkit.getImageUsingNamingSchemes(url,
            new Toolkit.MediaResolutionNamingScheme("-144dpi", 1.5f),
            new Toolkit.MediaResolutionNamingScheme("-192dpi", 2f)
    );
    loads resolution variants image-144dpi.png and image-192dpi.png for 
the base image.png image.

    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.

   Thanks,
   Alexandr.
>
> Obviously the ideal is the image is exactly what the naming convention
> implies it is, but what if it is not ?
>
> This issue does exist already even in JDK 8 .. if the
> @2x image is really 1.5X the @1 image
>
> Consider what happens if this contradicts the floating point scale ?
> It appears to me that as implemented, in practice, the app could call 
> it "@XXX",
> and once @XXX has been used to find the file, the only thing that actually
> matters is the floating point scale.
>
> So the naming schema is not important when they provide the scale.
>
> But we still have the issue that the *actual* image size may not be
> what they said it was  - either explicitly or by convention.
>
> Supposing what is claimed to be a 1.5x1.5 scale image is actually
> 1.0x2.0 times the size of the base image ? It is not even uniform.
>
> Ultimately what needs to "win" is the w:h ratio of the base image
> and we generally would want to pick whichever image best works
> for the actual device scale, based on the *real* dimensions of
> the hi-res image, don't we ?
>
> In which case, I'd expect us to work out the scale automatically.
> It is WID_HIRES/WID_BASE x HGT_HIRES/HGT_BASE
>
> At which point why do we even need the app to tell us anything
> except the (full) names of the files where to get the set of images,
> with the first one being the base .. or perhaps it should always
> be the "smallest".
>
> Otherwise if any are in fact smaller (or the same as) BASE .. do we 
> just discard them ?
>
> -phil.
>
> On 9/19/16, 12:03 PM, Alexander Scherbatiy wrote:
>> Hello,
>>
>> Could you review the updated fix:
>> http://cr.openjdk.java.net/~alexsch/8163854/webrev.01
>>
>> 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).
>>
>> Thanks,
>> Alexandr.
>>
>> On 25/08/16 05:39, Philip Race wrote:
>>> FWIW I think the most important image loading use case
>>> is that some generic resource loading code - perhaps JDK code - will 
>>> get a URL for where
>>> the resources are and go hunting. It is never going to call this API 
>>> .. so
>>> it had better be an optimisation and not a necessity
>>>
>>> -phil.
>>>
>>>
>>> On 8/24/16, 5:24 PM, Philip Race wrote:
>>>> Alexander,
>>>>
>>>> Were  the existing Toolkit.getImage(String/URL) APIs not enhanced to
>>>> do this for you automatically ? I suppose I thought they were but
>>>> they can't be since you are using getImage(String) here.
>>>>
>>>> IMO that would be more important than this.
>>>>
>>>> And in any case I don't see why this is solved only for local files.
>>>>
>>>> I am *not* asking for that right now. I am asking if the existing 
>>>> Toolkit APIs
>>>> can load a multi-res image and if not, why not  and can we fix that 
>>>> instead ..
>>>>
>>>> -phil.
>>>>
>>>> On 8/24/16, 9:36 AM, Alexander Scherbatiy wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> Could you review the fix:
>>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8163854
>>>>>   webrev: http://cr.openjdk.java.net/~alexsch/8163854/webrev.00
>>>>>
>>>>>   The public API which allows to load an image with resolution 
>>>>> variants based on the provided media resolution naming scheme is 
>>>>> added:
>>>>>   - Toolkit.MediaResolutionNamingScheme class
>>>>>   - Toolkit.getImageUsingNamingSchemes(String fileName, 
>>>>> MediaResolutionNamingScheme... namingSchemes)
>>>>>
>>>>>   A simple example for images which use naming scheme @150pct for 
>>>>> scale 1.5 and @2x for scale 2 is:
>>>>>     image_name.ext
>>>>> image_name at 150pct.ext
>>>>> image_name at 2x.ext
>>>>>
>>>>>     Toolkit toolkit = Toolkit.getDefaultToolkit();
>>>>>     Image image = toolkit.getImageUsingNamingSchemes(fileName,
>>>>>             new Toolkit.MediaResolutionNamingScheme(“@150pct”, 1.5f),
>>>>>             new Toolkit.MediaResolutionNamingScheme(“@2x", 2f)
>>>>>     );
>>>>>
>>>>>   Thanks,
>>>>>   Alexandr.
>>>>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20160922/eaf99592/attachment.html>