This is useful on headless Linux systems. When no display is attached,
window creation is bypassed but a StandalonePluginHolder is still
created, allowing audio to be processed.
Previously, MouseSourceState::checkButtonState would trigger a menu item
if the MouseSourceState had observed the mouse button transition from
pressed to released while over an item, after more than 250ms had
elapsed since creating the menu window. In situations where the main
thread was very busy, this timeout could sometimes be reached inside the
same mouse click/release gesture. If the menu was created inside a
mouse-down, then simply tapping the mouse could sometimes trigger an
item from the menu as soon as the menu window appeared.
To help avoid accidentally triggering menu items, the menu window now
prevents any item from being triggered by the mouse until either the
mouse has been released once, or the mouse has moved. Put another way,
if the mouse is initially pressed when the menu is shown, it cannot
trigger a menu item unless the mouse is moved before it is released.
This was evident in the FontsDemo when using the CoreGraphics renderer,
selecting a font without an italic face, and enabling the italic style.
The glyph anchor positions were incorrectly transformed by the text
matrix, causing the left margin of the text to become tilted.
We now correct for the slant and scale specified in the text matrix when
computing glyph anchor positions.
This fixes an issue where Direct2D will emit an error when using dirty
rects on the first full frame after resizing.
The issue isn't present on all hardware/drivers, but was observed on a
Windows 11 computer with a 890M iGPU.
Partially reverts a change made in
362a1cc070.
The factory needs to be multithreading-enabled in order to support e.g.
drawing to the screen on the main thread and drawing to an Image on a
background thread, even when no resources other than the graphics device
are shared between the two threads.
Previously, IDXGISwapChain::Present was called on a background thread,
which made it difficult to avoid race conditions. e.g. during a
live-resize of a window, we would occasionally draw old incomplete
frames instead of new frames at the correct size.
The new approach moves the Present call to the main thread via
AsyncUpdater. We attempt to present whenever the swap event wakes, and
whenever a frame is drawn. Only a single Present call may be made after
the swap event wakes. Subsequent Present calls will be ignored until the
next time the swap event wakes.
The waiting is only added on iOS 18 as this is the only platform where
seems to be an asynchronous relationship between
(1) AVAudioSession setActive:
(2) AVAudioSession setPreferredIOBufferDuration:
and (3) AVAudioSession.IOBufferDuration.
The issue is not observable in the iOS 18 emulator.
All NSUserNotification related classes have been deprecated in MacOS 11,
and this class will have to be revamped to use the new User
Notifications framework. We are suppressing the warnings for the time
being.
WebView2 can emit COREWEBVIEW2_WEB_ERROR_STATUS_CONNECTION_ABORTED
errors during page navigation, even if the page navigation would happen
correctly afterwards. In such situations our internal error handler can
recursively encounter this error when trying to navigate to the error
handler page.
Prior to this commit the implementation could end up in an infinite loop
receiving the error and then navigating to the error handler page.
This reverts 515e9b9f89.
In order to avoid recursive calls through WM_NCHITTEST, we remove calls
to Component::contains in DocumentWindow::findControlAtPoint.
For some transforms, the program could get stuck in the following loop:
- The content component emits a resized/moved notification, leading to
the initial call to Viewport::updateVisibleArea.
- New positions are computed for the viewport scrollbars, and scrollbar
listeners are notified synchronously that the scrollbars have been
updated.
- The viewport itself listens to the scrollbars, so it receives a
notification and updates the position of the content component.
- The scrollbar position (quantised to an integer) resolves to a
component position (also quantised to an integer) that differs from
the existing position, so the new position is applied.
- The viewport now attempts to set the scrollbars to the correct
position in response, and notifies listeners that the scrollbars
have moved...
Normally, the recursion would exit at the point where the component position
is set to its current position. If we're unlucky, though, converting
from view pos to scrollbar pos, then scrollbar pos back to view pos may
result in a view pos that differs from the original value.
This fix adds a new exit condition from the recursion. On receiving a
scrollbar move notification, we check whether the scrollbar position
computed from the current view position matches the incoming scrollbar
position. If it does, there's no need to compute and apply a new view
position from the incoming scrollbar position.
This allows for styles other than normal/bold/italic/bold-italic to be
selected, and more closely matches the behaviour of font selection on
other platforms.
