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.
- Improve default performance when components check if they are opaque
- Allows all components to take advantage of setPaintingIsUnclipped
- Give more control to opt out of opaque checks separate from setPaintingIsUnclipped
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.
initWithWindowScene appears to create a window with no area if the
provided scene is null. As a fallback, creating a window without an
associated scene still returns usable bounds.
The old implementation had a few problems:
- For a target area near but not touching the bottom of the parent area,
and a long menu with an initially-visible item halfway through the
list, the initially-visible item would sometimes be obscured by the
scroller area. The new implementation adjusts the size of the menu to
ensure that there's enough additional room for the scroller areas.
- For a target area at the very top or very bottom of the target area,
the menu would be positioned inconsistently; sometimes it would
overlap with the target area, but other times it would be positioned
with a gap separating the menu and target area. In the new
implementation, if there's not enough room for scrollers to be
positioned above/below the target area, the menu will always be
positioned so that it touches but does not overlap the target area.
- The initially-selected item would normally be
positioned as close as possible to the target area, but this wasn't
always applied consistently for long menus, and the menu would
sometimes only be scrolled enough to make the item visible at the end
of the menu furthest from the target area. In the new implementation,
the initially-visible item will always be positioned on top of the
target area, or adjacent to it, depending on the available space.
This makes it a bit easier to see exactly which PopupMenu state is used
during the calculation, and enforces that no menu state is modified
during the call.
