RFR: 8301616: Drag & maximize to another monitor places window incorrectly (Windows)

Nikita Gubarkov duke at openjdk.org
Thu Feb 2 21:17:30 UTC 2023


On Thu, 2 Feb 2023 20:36:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The `AwtWindow::CheckWindowDPIChange()` hack was introduced for popup windows and breaks maximization logic, so reshape window only if it's not maximized.
>
> src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 2190:
> 
>> 2188:         Devices::InstanceAccess devices;
>> 2189:         AwtWin32GraphicsDevice *device = devices->GetDevice(m_screenNum);
>> 2190:         if (device && !::IsZoomed(GetHWnd())) {
> 
> How does the maximization+drag work in WIndows11 if the maximized bounds are set(so the window will not fill the whole screen)? It will reset the zoom state during the drag, it will maximize the window on the new screen, or it will rescale the window on the new screen?

Maximized bounds are treated as absolute virtual screen coordinates, when maximized, window will be reshaped to that specific bounds no matter what monitor it is currently on. That is, when dragging to fullscreen from monitor 1 to 2 while maximized bound are in 1st monitor, it will just jump back and maximize there.
Also when maximized bounds are set, window looks awful on Win11 with caption looking wider than client area, but that's another topic.
So I found that my fix breaks maximized bounds logic - window jumps somewhere outside the monitor.
I guess we can apply this `AwtWindow::CheckWindowDPIChange()` jump for maximized windows, but only for those components which are overriden by maximized bounds (not `Integer.MAX_VALUE`).

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

PR: https://git.openjdk.org/jdk/pull/12367



More information about the client-libs-dev mailing list