Prior to this commit it was possible for the WebBrowserComponent
implementation on Windows to end up in an infinite loop if multiple
WebBrowserComponent objects were being created at the same time.
When an instance was already being created, the createWebView() call for
the second would place it in a queue and return without initiating its
creation. When the first WebView finishes creation, it calls the
handleAsyncUpdate() function of the second. However handleAsyncUdpate()
would see that the webViewBeingCreated helper variable was already true
and not call createWebView(), hence the second WebView would never be
created.
If, in the meantime, the scriptsWaitingForExecution variable wasn't
empty, handleAsyncUpdate() would endlessly call triggerAsyncUpdate().
Before this change, when starting a mouse drag from a nested view such
as a webview, JUCE was unable to automatically determine which component
is associated with the drag.
Instead of relying on automatic detection, users can pass the
"sourceComponent" argument when initiating a drag to specify the parent
view that should receive associated drag events. However, previously the
sourceComponent was only used to find the view associated with the
mouse-down, but not the mouse-up. Automatic detection was always used
for the mouse-up, but this could fail in the case of a drag started from
a nested view.
Now, the drag event source will store a weak reference to the source
component provided by the user, and use the same component for both
mouse-down and mouse-up events.
This restores the JUCE 7 behaviour when the JUCE 8 font fallback
mechanism fails to resolve a non-null Typeface::Ptr. This behaviour is
significant when the base font specified is not available on the system.
Since b108fe26c3, JUCE NSViews have
ignored mouse movements for child views. However, this causes issues for
OpenGL views, which still expect to receive mouse input via the parent
view. This fix makes the inner OpenGL view effectively invisible to the
mouse, so all mouse events are handled by the owning JUCE view.
The issue prior to this commit would be observable when using the
GlyphArrangement functions e.g. addFittedText.
This is a fix for a regression introduced in
9223805b9c.
Previously, the vblank's thread loop would block on each iteration until
the current async callback had finished, at which point a new async
callback would be immediately triggered.
The new implementation only waits on the vblank event. If a vblank
callback is still in progress the next time the vblank event is
signalled, we assume the last frame is overrunning and avoid sending a
new async update.
The intention of this change is to avoid saturating the message thread
with expensive vblank callbacks. It's also nice to remove a lock,
although that's just an incidental change.
This issue could be observed in the GraphicsDemo's SVG pane, when the
"rotation" option was enabled.
Drawables internally enable the unclipped painting flag, which normally
prevents slow clipping when drawing subcomponents of the drawable.
The Direct2D graphics context was using the frame area as the default
area, used to signal that no clipping should be applied. However, when
non-axis-aligned transform was active, this area was incorrectly applied
as a geometric clipping region. D2D geometric clips are relatively slow,
so this caused large slowdowns.
This solution adds a flag that is set whenever a clip is explicitly
requested. If no clip is explicitly requested, then clipping will be
entirely bypassed. This can make rendering of Drawables significantly
faster.
