[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Integrated: 8282863: java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails on
From:       Dmitry Kulikov <duke () openjdk ! java ! net>
Date:       2022-05-31 10:18:43
Message-ID: nsXFu1EA_JpHw8LvTt0LfhYSfRgHgRcTqFawUq35sxw=.171f76b6-21c9-420d-8aeb-c21b4e47e903 () github ! com
[Download RAW message or body]

On Wed, 16 Mar 2022 07:39:21 GMT, Dmitry Kulikov <duke@openjdk.java.net> wrote:

> Hello,
> Please review this fix for JDK-8282863.
> 
> The failing `java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java` \
> test basically checks that full-screen window remains full-screen when a display \
> mode change occurs. It has been introduced in JDK-8211999, which also contains \
> numerous fixes for HiDPI displays. In particular, JDK-8211999 changed the code of \
> `Win32GraphicsDevice.setDisplayMode()` so that it uses screen dimensions in user \
> space instead of device space, which is correct. However, if the display mode \
> change incurs display scaling change, as it has been observed on Windows 10 laptop \
> with HiDPI screen, the method used for obtaining screen bounds in user space \
> returns incorrect values under certain conditions. 
> The issue is reproducible on Windows 10, when resolution of the primary screen is \
> higher than 1024x768 with scaling greater than 100%. Resolution and scaling of \
> secondary screen(s) is irrelevant. I used a laptop with 2160x1350 display \
> resolution and scaling set to 150%. When the \
> `java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java` test is run \
> with these initial conditions, roughly the following happens: 
> 1. `java.awt.Frame` is created and set as full-screen.
> 2. `Win32GraphicsDevice.setDisplayMode()` is called to change screen resolution \
> from 2160x1350 to 1024x768. 3. `Win32GraphicsDevice.configDisplayMode()` call \
> immediately changes the display resolution to 1024x768, which also incurs the \
> immediate display scaling change from 150% to 100%. 4. Inside the \
> `Win32GraphicsDevice.setDisplayMode()` screen bounds in user space are obtained via \
> `Win32GraphicsConfig.getBounds()`: 5. In the native code of \
> `Win32GraphicsConfig.getBounds()` new screen bounds in device space (1024x768) are \
> correctly obtained via `MonitorBounds()`. 6. Then screen bounds are converted to \
> user space by applying **scaling factors, which are not yet updated and correspond \
> to previous display mode**. In our case, 1024x768 is scaled down by 150% and \
> becomes 683x512. 7. Back in `Win32GraphicsDevice.setDisplayMode()` full-screen \
> window bounds are set to incorrectly scaled 683x512 instead of 1024x768. 8. After \
> returning from `Win32GraphicsDevice.setDisplayMode()` the test waits 4 seconds. 9. \
> `WM_DISPLAYCHANGE` message is received and processed, followed by `WM_DPICHANGED`, \
> which updates the scaling factors used by `Win32GraphicsConfig.getBounds()` to the \
> correct value of 100%. 10. After 4 seconds test wakes up and obtains screen bounds \
> in user space by calling `Win32GraphicsConfig.getBounds()`, which now correctly \
> returns 1024x768. 11. Test compares full-screen window bounds with screen bounds, \
> and fails with `java.lang.RuntimeException: width is wrong` as 683 is not equal to \
> 1024  ± 30 pixels. 
> Proposed fix adds a `Win32GraphicsDevice.initScaleFactors()` call to \
> `Win32GraphicsDevice.setDisplayMode()` code, between calling \
> `Win32GraphicsDevice.configDisplayMode()` and `Win32GraphicsConfig.getBounds()`. \
> This updates the scaling factors without waiting for `WM_DISPLAYCHANGE` or \
> `WM_DPICHANGED`, `Win32GraphicsConfig.getBounds()` returns correctly scaled screen \
> bounds in user space, and full-screen window remains correctly sized after display \
> mode change. 
> I've run tests from `jdk_awt` group on Windows 10 using a laptop with the same \
> settings that caused the issue (primary screen with 2160x1350 resolution and 150% \
> scaling), and applying the fix did not introduce any new test failures.

This pull request has now been integrated.

Changeset: c6e04164
Author:    Dmitry Kulikov <projectd8@yandex.ru>
Committer: Alexey Ivanov <aivanov@openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c6e041649514b964f5baaa88880c4d146275db8d
                
Stats:     29 lines in 2 files changed: 21 ins; 4 del; 4 mod

8282863: java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails \
on Windows 10 with HiDPI screen

Reviewed-by: serb, aivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/7835


[prev in list] [next in list] [prev in thread] [next in thread]