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.

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.

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.


--
Best regards, Sergey.

Reply via email to