<AWT Dev> RFR: 8212226 SurfaceManager throws "Invalid Image variant" for MultiResolutionImage (Windows)
Sergey.Bylokhov at oracle.com
Fri Jul 24 21:28:45 UTC 2020
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.
> 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
>> 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.
More information about the awt-dev