This bug was introduced in b4c28db765.
The argument to contains() is in peer space (logical pixels relative to
the peer's top left). To convert to relative physical pixels, logical
pixels should be multiplied by the peer's scale factor, *not* divided.
258203706c introduced a problem where
live-resize of a window would cause the window content to flash and slow
down.
The cause of the errant behaviour seems to be that, during resize, many
WM_PAINT messages might be dispatched over the course of a single vblank
interval. Then, each of these paint calls was waiting for the next
vblank interval to display. This additional waiting resulted in
sluggishness, since many frames would have to be presented before the
presentation 'caught up' with the current window size. This also meant
that many consecutive frames were presented with stale window size
information.
The solution added here simply checks whether we're live resizing, and
uses the vblank instead of WM_PAINT to synchronise repaints during the
resize operation.
D2D repaints are always driven by a vblank timer, and D2D presentation
can't happen any faster than the vblank callbacks, so I think it's safe
to remove the swapchain machinery and to rely entirely on the vblank
callbacks instead.
This issue presented after the following sequence of steps:
- Display a window with a non-native titlebar
- Maximise it
- Click the taskbar icon to minimise it
- Click the taskbar icon again to maximise it
After being maximised for the second time, the window bounds were too
large for the display. This is because the check in WM_NCCALCSIZE was
failing to determine the target monitor for the window, and therefore
failing to adjust the new area appropriately. We now determine the
target monitor based on the proposed new bounds of the new window,
rather than the current bounds of the window, which may not be
meaningful if the window is minimised.
On at least iOS 26 using a temporary window frame is unreliable. This
change tries to use an existing window for any non-standalone app. It
also updates the details on any changes, such as when the device
orientation changes.
handlePositionChanged() is called when the window changes z-order, which
may cause a new mouse event to be synthesised if the mouse is over the
window after the z-order is updated. In this situation, we may not have
received a mouse up/down/move event to update the current modifier
flags, so we need to update them ourselves.
This is a different approach to the change introduced in
04f87320d5.
Instead of completely recreating the window, we now just update the
window's style flags. This should ensure that window and component focus
are preserved.
This follows on from the work in
3e70c37ce3.
The previous patch had the intended effect as long as the peer was
recreated after entering kiosk mode. However, for windows initially
created with non-native titlebars, attempting to disable the titlebar
would have no effect.
We now check whether the native style flags would need to change as a
result of changing kiosk mode, and recreate the peer if necessary.
467f20a7a1 introduced a change to start processing WM_NCMOUSELEAVE
messages as mouse-exit events. This behaviour is not quite correct,
because NCMOUSELEAVE may be triggered when moving the cursor from the
nonclient area to the client area, in which case the mouse is still over
the window.
We now check whether the mouse is really over the window inside
doMouseExit(), and continue to track it if necessary.
This bug could be observed by running the WidgetsDemo Drag+Drop pane on
Windows 10, and dragging an item between two displays at different scale
factors.
This is issue is a regression introduced in
9817a2bb66. The regression was caused by
the change in mouse position calculation. The incorrect version switched
to using ClientToScreen, but the correct version used
getPointFromLocalLParam.
The function getPointFromLocalLParam was replaced by clientLParamToPoint
in 24ab3cb6a3, and is restored by this
commit.
