This fixes a bug on iOS 17 running on a 9th gen iPad.
- Set JUCE_IOS_AUDIO_EXPLICIT_SAMPLERATES=44100,48000,88200,96000
- Start the DemoRunner.
- Add a breakpoint in AudioDeviceManager::audioDeviceAboutToStartInt().
- In the DemoRunner, change the sample rate to 96000.
- The breakpoint will fire. Observe the value of
getCurrentBufferSizeSamples().
- Move the breakpoint to audioDeviceIOCallbackInt and continue
execution.
- The breakpoint will fire. Observe the value of the numSamples
parameter.
numSamples should always be no larger than the sample count reported in
audioDeviceAboutToStartInt().
Before this change, it was possible for getCurrentBufferSizeSamples() to
return a value smaller than the buffer size of subsequent process
callbacks.
Removing the availability checks and unconditionally
deactivating/reactivating the device seems to fix this issue, and the
correct buffer size is returned immediately when the device is
(re)started.
We've already had a mechanism in place which loads these libraries, such
as libwebkit2gtk-4.1.so, only if they are available on the system during
runtime. This way we can run with either version 4.1 or 4.0 of the
library depending on which one is available.
It's also possible to run apps on headless systems with the relevant
features being effectively disabled in such situations.
wglShareLists will only succeed when the shared context is not currently
active on another thread, but it is difficult to ensure that the GL
thread is paused/inactive at any given time - in particular, it's very
easy to accidentally introduce deadlocks where the main thread waits for
the render thread's lock while the render thread waits for the
messagemanager lock.
The simplest way to ensure that no other thread has activated the shared
context is to share the contexts directly on the render thread itself.
This avoids an issue where, when attaching an OpenGLContext as a child
of a window rendered with Direct2D, the area covered by the OpenGL
renderer would display as a white rectangle until the context had
drawn a frame. This only affected the Direct2D renderer; when the parent
window used the software renderer, no white rectangle was shown.
The assertion can routinely fire on Linux, where a window may go through
many size changes from (0, 0) to its actual size due to the nature of
how XWindow reports these in subsequent ConfigureNotify events.
These subsequent changes aren't visibly observable by users.
There were a few "ambiguous operator new/delete" errors that were due to
inheriting from a private base class that used the leak detector. These
errors are resolved by adding the leak detector to the derived classes.
JUCE_API was missing from a few useful types, notably the ARA hosting
types.
Previously, it was possible for the Timer destructor to run after the
last ScopeJuceInitialiser_GUI destructor, which meant that timer
callbacks could continue to be fired (via the appDelegate pointer) after
the static appDelegate instance had been destroyed.
With this change in place, we now ensure the Timer is destroyed before
the ScopedJuceInitialiser_GUI.
This fixes an undesired behaviour where squashing the text using
GlyphArrangement::addFittedText would only squash the visible glyphs but
not the additional kerning space between them.
This commit fixes a regression added during the ShapedText based rewrite
of the class. The minimumHorizontalScale parameter was mistakenly
interpreted as an absolute scale, whereas its meaning in the old
implementation was a relative scalar applied to the Font's horizontal
scale.
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.
