Hi,
you right - my memory played tricks on me, there was a method that
says first image in a set is considered a
base image - i believe that was one of the constructors of the
BaseMultiResolutionImage and that somewhat
settled in my head. Yes, calling getResolutionVariant() is the right
thing to do. See updated webrev at
http://cr.openjdk.java.net/~kizune/8212226/webrev.02/
As for the test i have a manual test that i use to reproduce the
situation but i am not sure i can make
the automated test case - the configuration required is quite unique. I
tried to play with the setting
that manages the magnification factor but changing it does not trigger
the bug.
/Alex
On 7/24/2020 2:28 PM, Sergey Bylokhov wrote:
Hi, Alexander.
I am not sure that access to default resolution via index "0" is the
right thing to do:
- Default resolution is not necessary located as a first image, for
example in
the BaseMultiResolutionImage it is possible to specify the index of
the base image.
- To access the image by the index you will need to call
getResolutionVariants, which
will load all resolution variants even if most of them are unusable.
I think it is better to call: getResolutionVariant(width, height);
since the default resolution
has the same size as the image itself.
Do you have a chance to create a small test for this use case? I think
it will be useful.
On 20.07.2020 16:45, Alexander Zuev wrote:
Hi Sergey,
the new fix can be found here:
http://cr.openjdk.java.net/~kizune/8212226/webrev.01/
I did exactly that - i am trying to substitute the image variant
with the base image and only if it
fails i'm returning false. So far i saw no regression with this
approach.
/Alex
On 6/30/2020 5:05 PM, Sergey Bylokhov wrote:
On 6/29/20 7:37 am, Alexander Zuev wrote:
It also means that if a non-primary variant will never be loaded,
we still should be able to draw the default variant.
Well - in certain cases the primary variant is not being loaded too
which causes the same exception -
what should we do then? There's literally nothing to show in this
case.
Right, in this case, we will return "false" since the image and its
scaled version are nor ready/loaded yet,
but we need to check that the observer passed to the method will be
called when the image will be loaded.
On the other hand
later in the same method when we are scaling the image for custom
scaling factor we are checking
if the imagepipe is ready and if not - we do return false knowing
that this method will be called again later
and we will be able to paint image correctly.
And i think it is the correct way of handling such situation. I can
in case of image not being ready try to get the
base image from MRI - and only when IT is not ready to return fail.
But returning fail indicating we haven't
drawn an updated image is a way to go.
The boolean flag in this message does not necessarily mean error
during image loading,
we may try to draw the image, but it could not fully be completed
and the observer will be called
later.
The reasons could be:
- The image loading is in progress, and we draw only the part of
the image
- Only low-quality image is drawn, so we need to redraw good
quality image later
But from the other side, we may load the low-quality image on the
HiDPI environment
while it is not strictly necessary. I have no personal preferences
for this, so the
current fix looks fine, but please check that the observer really
will be called later
if the MRI resolution variant is not ready yet.
