<AWT Dev> RFR: 8212226 SurfaceManager throws "Invalid Image variant" for MultiResolutionImage (Windows)

[Alexander Zuev]

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.
>>>
>>>
>>>
>>
>
>