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.
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_n...@150pct.ext
image_n...@2x.ext
Toolkit toolkit = Toolkit.getDefaultToolkit();
Image image = toolkit.getImageUsingNamingSchemes(fileName,
new Toolkit.MediaResolutionNamingScheme(“@150pct”,
1.5f),
new Toolkit.MediaResolutionNamingScheme(“@2x", 2f)
);
Thanks,
Alexandr.
