[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 18:03:09 UTC 2016
Also as I pointed out before a string specified per-variant is not a
naming *scheme*.
It is just a "per-file" add-on to the basename
I could use
Image image = toolkit.getImageUsingNamingSchemes(url,
new Toolkit.MediaResolutionNamingScheme("abc", 1.5f),
new Toolkit.MediaResolutionNamingScheme("foo", 2f)
to load files "img.png", "imgabc.png", and "imgfoo.png"
That doesn't look like a consistent scheme at all ...
so give up on that and just have them list the full names and
get rid of the unneeded API.
-phil.
On 9/22/16, 10:56 AM, Philip Race wrote:
> > The method getImageUsingNamingSchemes(String fileName,
> MediaResolutionNamingScheme...
> > namingSchemes) works for any scheme not only for the default one.
>
> I'm sure it does. My point is that we don't need it.
> No one will care or use it. They just want to list their image files.
>
> The naming scheme is only important for the cases when people
> are NOT supplying an explicit list of images to getImage.
> So public API for the naming schema - or the float scale - is
> completely unnecessary
> bloat and complication.
>
> -phil.
>
> On 9/22/16, 10:23 AM, Alexandr Scherbatiy wrote:
>> 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/69b4dacf/attachment.html>
More information about the 2d-dev
mailing list