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.
This commit partially reverts 07f801143c.
While it's justifiable that triggerClick() is guarded and ineffective
when the button is disabled, setToggleState() needs to work to correctly
represent the underlying parameter state.
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.
Reverts commits cea19a9d, 961ff32b, and partially reverts 5ec4d85d
Some issues have appeared on the forums so these commits have been
reverted while the issue is investigated.
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.
Prior to this commit a Component with setBufferedToImage (true) could
have its image buffer deleted when an OpenGL context was detached. This
meant that this Component continued to be rendered without buffering
even though it was previously requested that it use a buffer.
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.
