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

[Alexander Zuev]

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.
>
> I think the current bug is a variation of 
> https://bugs.openjdk.java.net/browse/JDK-7183828
> and we hit the same assertion using non-BufferedImage image, in our 
> case MRI.
That might be the case.
> BTW I am not sure that it is related to JDK-8182043. The 
> FileSystemView/Win32ShellFolder2 create
> the MRI on top of BufferedImages, which return its height/width 
> synchronously in the SunGraphics2D.drawHiDPIImage.
Well, right now the MRI in FileSystemView is never used for the reasons 
i stated in the JDK-8182043
review - we never reach the code that initializes it.
>
> The "Invalid Image variant" exception can occur only if ToolkitImage 
> is used(it is loaded via
> Toolkit.getImage/createImage), this is probably the reason why the bug 
> is not reproduced easily.
>
>