When handling WM_NCCALCSIZE, we reduce the size of the client area when
the window is maximised. If we don't do this, then the client area
matches the top-level window area, which is larger than the display's
safe area. As a result, the window appears too large, and the edges are
obscured under the edges of the display.
After reducing the client area in WM_NCCALCSIZE, the client area is no
longer equal to the top-level window area, so getBounds() must be
updated to return the window's *client* area rather than the top-level
window area.
The change to the VST3 wrapper in
335f6e9591 broke context menu items in FL
Studio, so that clicking on a menu item had no effect. This could be
seen in the DSPModulePluginDemo example.
I'm not sure exactly what caused the breakage. Before the breaking
change, the menu remained alive until the point where the menu item was
triggered as it was leaked. After the breaking change, the IContextMenu
could be freed before a particular IContextMenuTarget was executed. My
guess is that FL Studio requires the menu to be alive when triggering a
particular menu item.
This change captures the IContextMenu inside the popup menu callback to
ensure that it remains alive until the PopupMenu is destroyed.
Previously, stable_sort was used to reorder note-ons and note-offs, with
the intention that note-offs would always be ordered before note-ons
with the same time stamp. However, stable_sort requires the comparator
to be a strict-weak ordering, which was not the case for the previous
implementation.
Additionally, the old implementation could unnecessarily reorder events.
Note ons and offs only need to be reordered if the note numbers and
channels match. It's fine for a note-on to be ordered before a note-off
if the note itself is different.
The new implementation only uses stable_sort to order events by
time-stamp. Then, for each range of events with matching timestamps, the
first note-on event will be swapped with the last following note-off
event with matching channel/number.
When the display goes to sleep IDXGIOutput::WaitForVBlank returns S_OK
immediately causing the VBlankThread to consume a core entirely with the
VBlank related messaging.
To limit this problem, we use the same technique as Chromium presently
does, and we sleep for 1 ms, if the time between the last two VBlank
events was less than a ms. This limits the VBlankThread messaging rate
of about 50.000/s on an Intel 13600 to 1000/s.
Without this change, the mouse state was not always updated after
releasing the mouse, leaving the current modifier keys with the
left-mouse-button bit set. This was particularly evident in standalone
plugins, where clicking the 'options' button in the titlebar, then
immediately clicking the titlebar could "stick" the window to the mouse,
making it impossible to interact with the window normally.
The same run loop may be registered multiple times, e.g. if the host
passes the same run loop pointer to multiple instances of the plugin.
When a particular run loop client goes out of scope, it should only
remove its own reference to the run loop, because other clients may
still be active and still using that run loop.
Before this change, after running a JUCE app on Windows under a
debugger, and quitting it normally (e.g. pressing the close title
button), the output log would display some memory leak diagnostics. This
is because HarfBuzz expects to clean up statics using atexit, but atexit
was not enabled. This change enables atexit on supported platforms,
including Windows.
Previously, if the AudioProcessor had disabled buses, the AUv3 wrapper
would attempt to create zero-channel buses to represent the JUCE buses,
which failed.
With this change in place, disabled buses will be created with their
default layout, and then explicitly disabled.
The default background colour of the WebBrowserComponent is white on all
platforms. Before the first page finishes loading this is the colour
that should fill the WebBrowserComponent's area.
Prior to this change however, on Windows a sudden flash to the default
JUCE background colour would occur, before the default white background
could take effect.
At the time of this commit there is a known issue with the
icorewebview2controller2, where a white flash is inevitable, unless the
WEBVIEW2_DEFAULT_BACKGROUND_COLOR environment variable is set. Using
a white background behind the WebView avoids this issue.
This assertion was intended to emulate a performance warning that could
be emitted by the D2D debug layer, but it often gets in the way during
development. To check for this performance issue, users can change
D2D1_DEBUG_LEVEL_NONE to D2D1_DEBUG_LEVEL_INFORMATION in
juce_DirectX_windows.h
Calling getInstance may recreate the list singleton if it has already
been destroyed. This should only happen if a Typeface instance is being
destroyed after the app/plugin has been shutdown, e.g. if the typeface
has static storage duration.
This fixes potential crashes when this static object is accessed from
the constructors of other objects with static storage duration.
A concrete example of this could be seen when running the following on
Linux:
static inline const Typeface::Ptr face =
Typeface::createSystemTypefaceFor (...);
Here, 'face' is a static data member of some class. Creating a system
typeface on Linux will parse an XML document of system typefaces,
eventually accessing juce_xmltextContentAttributeName.
This issue could be seen when calling setBufferedToImage on a component
with a transparent background with a size different to the component's
size.
The details are unclear to me, but it seems like both calling Clear on
the device context, and using the COPY blend mode, ignore alpha values
and instead use a constant alpha of 1.0 when there is a geometric
clipping layer active.
As a workaround for this issue, when clearing a rectangle we now pop all
active layers, fill their intersection using the COPY blend mode while
there are no layers active, and then reinstate the layers.
The new implementation is likely to be very slow, however I think this
code path is unlikely to be used frequently in practice. The main
use-case for rendering clear transparent areas is the rendering of
buffered component images, but such cases normally use axis-aligned
clipping regions, which should be able to use the faster path.
