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

[Sergey Bylokhov]

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


-- 
Best regards, Sergey.