<AWT Dev> RFR: 8212226 SurfaceManager throws "Invalid Image variant" for MultiResolutionImage (Windows)
Alexander Zuev
alexander.zuev at oracle.com
Mon Jun 1 17:49:19 UTC 2020
Hi Sergey,
On 27-May-20 21:36, Sergey Bylokhov wrote:
> Hi, Alexander.
>
> On 5/27/20 8:53 am, Alexander Zuev wrote:
>> There is no regression test since even for the manual regression
>> test the setup would be quite difficult - you will have to have not
>> just the multi-monitor configuration, but the configuration where on
>> different displays you have different magnification factor. I tried
>> to simulate different magnification factor by changing
>> sun.java2d.uiScale parameter but that does not trigger the problem,
>> image gets repainted correctly and no exception happens.
>
> 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.
More information about the awt-dev
mailing list