Previously, plugins and standalone apps could produce slightly different
visual results, particularly anti-aliasing, when displaying on a display
with native scaling applied. The discrepancy was caused by SetDpi being
called with a larger-than-default value (e.g. 192 DPI on a 200% scaled
display) in a standalone app, whereas SetDpi would always be called with
the default value of 96 in a plugin.
Keeping the default value seems to produce better results, so standalone
apps will now retain the default DPI.
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.
