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

Philip Race philip.race at oracle.com
Thu Sep 22 17:52:49 UTC 2016

Why do we need a new issue ?
I don't see how this fix can proceed without a lot of changes along
the lines I suggested and that should (must even) be part of it.


On 9/22/16, 10:41 AM, Alexandr Scherbatiy wrote:
> On 9/22/2016 11:30 AM, Jim Graham wrote:
>> It gets further complicated, though, when you consider that we 
>> probably need the dimensions of the base image for any metrics 
>> reporting anyway.
>> Consider a 25x25 image with variants.  If the user supplies a 125pct 
>> variant then they will need an image that is 31.25 pixels in size.  
>> Do they use a 31 pixel image or a 32 pixel image?  And if they offer 
>> one of those with the suffix that tells us that it is a 125pct image, 
>> then when we try to report the size, do we report it as:
>> 31/1.25 == 24.8 pixels == do we report 24 or 25?
>> 32/1.25 == 25.6 pixels == do we report 25 or 26?
>> In the end, we can't really report anything until we load the base 
>> image and discover that we should be reporting 25x25 to the observer 
>> and scaling all SOME_BITS notifications based on 25/31 or 25/32...
>> Given that we need the original base image size to do anything 
>> useful, it may be much more feasible to handle things as Phil 
>> suggests...
>   I have filled an issue on it:
>     JDK-8166566 Improper toolkit resolution variant scale should be 
> properly handled.
>       https://bugs.openjdk.java.net/browse/JDK-8166566
>   Thanks,
>   Alexandr.
>>             ...jim
>> On 9/21/16 5:48 PM, 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?
>>>                 ...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.
>>>> 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.

More information about the 2d-dev mailing list