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

[Alexander Zuev]

Hello Sergey,

   sorry for long delay. Please see my response inline below:

On 02-Jun-20 16:51, Alexander Zuev wrote:
> On 02-Jun-20 8:34, Sergey Bylokhov wrote:
>> On 6/1/20 10:49 am, Alexander Zuev wrote:
>>>> I remember that at some point it was attempted to implement that 
>>>> initially we draw the default image resolution(if the correct 
>>>> resolution variant is not ready yet.) Not sure that it actually 
>>>> works this way. If the current approach(when we try to draw the MRI 
>>>> itself) does not work, should not we try to use default resolution 
>>>> variant directly if the proper variant is not ready yet?
>>>>
>>> The problem here is that it really breaks logic of the drawImage as 
>>> intended by the documentation of the
>>> java.awt.Graphics.drawImage(). Its JavaDoc clearly says that if 
>>> scaled image is not ready to be painted then
>>> method should return false. That is exactly the case - as far as we 
>>> can tell at the first time we call the
>>> drawHiDPIImage its observer reports image as not initialized yet. 
>>> And getting the standard resolution image
>>> and scaling it might be problematic if the application started on 
>>> the display with magnification factor not equal to 1.
>>> I think it is the reason we have for exception on the startup when 
>>> waitForImage() method in the test case is
>>> commented out when we are starting on the 150% magnification factor 
>>> screen.
>>
>> That specification knows nothing about MRI and all its references to 
>> the "image"
>> are all about the main image which is passed to those methods. So to 
>> follow the spec we
>> should always draw something if the main image/its default variant is 
>> load already, we just
>> try to add an additional attempt to draw "better" resolution variant, 
>> but if it is not ready
>> we should try to draw the main variant.
>>
>> 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. 
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.

/Alex