<AWT Dev>  Review Request: 8231564 and 8176359
alexey.ivanov at oracle.com
Wed Jan 29 17:27:52 UTC 2020
The fix looks good to me.
The trick with WM_WINDOWPOSCHANGING should work to avoid covering the
Taskbar on the secondary monitor too.
On 26/01/2020 22:43, Sergey Bylokhov wrote:
> Please review the fix for JDK 15.
> Bugs: 8231564: setMaximizedBounds is broken with large display scale
> and multiple monitors
> 8176359: Frame#setMaximizedbounds not working properly in multi
> screen environments
> Fix: http://cr.openjdk.java.net/~serb/8176359/webrev.01
> Short description:
> The fix changes the way on how we limit the size and position of the
> maximized window.
> Long description:
> On Windows supports of maximized is done by the WM_GETMINMAXINFO
> message. This
> message provides MINMAXINFO which has two related fields: ptMaxSize
> and ptMaxPosition.
> ptMaxPosition: The position of the left side of the maximized window
> (x member) and
> the position of the top of the maximized window (y
> member). For top-level
> windows, this value is based on the position of the
> primary monitor.
> ptMaxSize: The maximized width (x member) and the maximized height
> (y member) of the
> window. For top-level windows, this value is based on the
> width of the primary
> "For systems with multiple monitors, the ptMaxSize and ptMaxPosition
> members describe the
> maximized size and position of the window on the primary monitor, even
> if the window
> ultimately maximizes onto a secondary monitor. In that case, the
> window manager adjusts
> these values to compensate for differences between the primary monitor
> and the monitor that
> displays the window. Thus, if the user leaves ptMaxSize untouched, a
> window on a monitor
> larger than the primary monitor maximizes to the size of the larger
> My observation:
> 1. Description of "ptMaxPosition" in the documentation is wrong,
> this value is based on the
> actual window's monitor not a primary monitor. I have read about
> it here and confirmed
> by the tests using three monitors setup.
> 2. ptMaxSize will be used as-is if the size is smaller than the
> !!main!! monitor. If the size
> is larger than the main monitor then the window manager adjusts
> the size, like this:
> // result = requested.w + (current.w - main.w); =>> This results
> in the correct size if we
> want to fully maximize the window on the current monitor, but if
> we want to set a smaller
> size then we will get the wrong result.
> We can try to compensate for this adjustment like this:
> // requested = requested.w - (current.w - main.w);
> but this can result to the size smaller than the main screen, so
> no adjustment will be
> done by the window manager =>> wrong size again.
> Note that the result does not depend on the monitor on which we
> maximize the window.
> 3. For example for the three monitors setup: W1=600, W2=1600,
> W3=1080. It is not possible
> to maximize the window on W3 if the current window is on W2
> monitor, because if we
> request size=1080 which is bigger than 600 and it will be
> adjusted by the window
> manager: resulted size = 1080+(1600-600) = 2080. If we will try
> to compensate this value:
> size = 1080 - (1600-600) = 80, which is smaller than main monitor
> and will be used as-is.
> Fix description:
> 1. To fix JDK-8231564 we should convert all coordinates from the
> user's virtual space to
> the device space.
> 2. To fix JDK-8176359 we need to translate the bounds.x/y from the
> global virtual coordinate
> system related to the main monitor to the coordinate system of
> the window's actual monitor.
> 3. The current code already tried to compensate adjustment, but it
> missed the fact that the
> width and height should be adjusted separately, but even if that
> be fixed, in some situations
> this logic will be broken(see observation point 3). So instead of
> fixing that I have passed
> these values to the native as-is, and cut the adjustment in the
> WM_WINDOWPOSCHANGING event,
> just before the window is resized.
> Known issue:
> - The current approach, as well as most of the API which uses user's
> space coordinates, does
> not work well if different scales are used for each screen and the
> coordinates "overlaps".
> - It looks like the user in the JDK-8231564 tried to avoid covers the
> taskbar by the maximized
> undecorated window, this is a know issue JDK-8022302.
>  https://devblogs.microsoft.com/oldnewthing/20150501-00/?p=44964
More information about the awt-dev