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

Thu Sep 22 17:31:32 UTC 2016

On 9/22/2016 3:48 AM, Jim Graham wrote:
> I think this is a good point.  The only gotcha would appear to be 
> handling the ImageObserver notifications and the prepareImage() calls.
>
> The ImageObserver should get the variant's dimensions as one of the 
> first notifications, though if they trigger an image load and then add 
> an observer later, I'm not sure if it will get the back-notifications 
> or not.  Also, it would need to know the base image dimensions, but 
> the base image may not be loaded yet due to lazy loading and/or 
> receiving the data for the @Nx version of the image before you receive 
> the data for the regular version.  All of those add complexity with 
> trying to figure out how to notify an observer of incoming information.
>
> So, lazy loading may make this approach infeasible.  Alexandr?
   Yes. The Toolkit.getImage(...) method does not  load the toolkit 
image. It is postponed to the time when it is drawn or just explicitly 
loaded by MediaTracker.
   When a resolution variant of a multi-resolution toolkit image is 
loaded it notifies its size/scale to the observer so the observer 
receives the base image size.

   Thanks,
   Alexandr.

>
>                 ...jim
>
> On 9/21/16 11:47 AM, 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".
>>
>> 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.
>>>>>>
>>>