mirror of
https://github.com/juce-framework/JUCE.git
synced 2026-01-10 23:44:24 +00:00
c24d1a17a7
This change intends to address a bug observed only on Windows 10 with a display scale factor of 125%. When the native titlebar is enabled, and the window's border-resizer is used to resize the window slowly the with mouse, the client area of the window may move to the wrong location, or be drawn with some areas obscured/clipped. This is especially observable when resizing the WidgetsDemo to its smallest size, and then dragging the right border a single pixel to the right. On my computer, this consistently causes the client area to display at the wrong location. I haven't been able to find any obvious bug in JUCE that might cause this behaviour. In particular, it seems that the window begins displaying incorrectly *before* the window ever actually resizes. During the resize, the system sends events (WM_SIZING and WM_WINDOWPOSCHANGING) to the window, and according to the documentation, the window may modify the message parameters in order to constrain the new window size. When running on a scaled display, JUCE attempts to map the logical client area size to a sensible size in physical pixels, and uses the sizing messages to enforce this size requirement. In the case of the broken window rendering, the system requests a new window size, which JUCE rejects. The window's display state doesn't change, so the swap chain does not resize, and the swap chain does not present. Put another way, the broken rendering happens *independently* of JUCE modifying the swap chain in any way. Therefore, I believe that the bug is introduced elsewhere, potentially by Windows itself. I also checked to see whether the issue could be caused by mishandling of the NCCALCSIZE message, which is normally used to configure the relative positions of the client and nonclient areas. However, in the buggy case, NCCALCSIZE is not sent until *after* the first 'broken' frame is painted - and even then, the implementation immediately falls back to DefWindowProc. Given that the issue appears to be a bug in Windows, the proposed change is a workaround, rather than a true fix. It appears as though the problem goes away when WM_WINDOWPOSCHANGING does not modify the requested bounds. Therefore, for windows with native titlebars, we rely on the constraints to be applied in WM_SIZING only, when sizing the window in a sizemove gesture. |
||
|---|---|---|
| .. | ||
| accessibility | ||
| java/app/com/rmsl/juce | ||
| javaopt/app/com/rmsl/juce | ||
| juce_CGMetalLayerRenderer_mac.h | ||
| juce_ContentSharer_android.cpp | ||
| juce_ContentSharer_ios.cpp | ||
| juce_DragAndDrop_linux.cpp | ||
| juce_DragAndDrop_windows.cpp | ||
| juce_FileChooser_android.cpp | ||
| juce_FileChooser_ios.mm | ||
| juce_FileChooser_linux.cpp | ||
| juce_FileChooser_mac.mm | ||
| juce_FileChooser_windows.cpp | ||
| juce_MainMenu_mac.mm | ||
| juce_MouseCursor_mac.mm | ||
| juce_MultiTouchMapper.h | ||
| juce_NativeMessageBox_android.cpp | ||
| juce_NativeMessageBox_ios.mm | ||
| juce_NativeMessageBox_linux.cpp | ||
| juce_NativeMessageBox_mac.mm | ||
| juce_NativeMessageBox_windows.cpp | ||
| juce_NativeModalWrapperComponent_ios.h | ||
| juce_NSViewComponentPeer_mac.mm | ||
| juce_PerScreenDisplayLinks_mac.h | ||
| juce_ScopedDPIAwarenessDisabler.cpp | ||
| juce_ScopedDPIAwarenessDisabler.h | ||
| juce_ScopedThreadDPIAwarenessSetter_windows.h | ||
| juce_ScopedWindowAssociation_linux.h | ||
| juce_UIViewComponentPeer_ios.mm | ||
| juce_VBlank_windows.cpp | ||
| juce_Windowing_android.cpp | ||
| juce_Windowing_ios.mm | ||
| juce_Windowing_linux.cpp | ||
| juce_Windowing_mac.mm | ||
| juce_Windowing_windows.cpp | ||
| juce_WindowsHooks_windows.cpp | ||
| juce_WindowsHooks_windows.h | ||
| juce_WindowUtils_android.cpp | ||
| juce_WindowUtils_ios.mm | ||
| juce_WindowUtils_linux.cpp | ||
| juce_WindowUtils_mac.mm | ||
| juce_WindowUtils_windows.cpp | ||
| juce_XSymbols_linux.cpp | ||
| juce_XSymbols_linux.h | ||
| juce_XWindowSystem_linux.cpp | ||
| juce_XWindowSystem_linux.h | ||