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 fixes an issue where the view would disappear and the window would
become black when the window scene changed, e.g. because screen sharing
was started.
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.
The important part seems to be initialising the UIWindow directly with
the UIWindowScene, instead of initialising it with a frame and then
assigning a scene later on.
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.
This also fixes an issue where endBackgroundTask wasn't guaranteed to be
called after suspended() completed. According to the docs,
endBackgroundTask must be called after the task completes.
