Previously, MIDI FX would report an input and output channel count of 0.
However, a non-empty output bus is required in order to retrieve the
processing sample rate.
With this change in place, MIDI FX plugins will now report an output
channel count of -1, which indicates that any number of output channels
is valid.
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.
Reading or writing the kAudioUnitProperty_AudioChannelLayout property
could result in out-of-bounds reads or writes as AudioChannelLayout
has a variable length array as the last member of the struct
Without this change in place, setting the Value to NaN can cause a stack
overflow because the old and new values always compare unequal, causing
new change notifications to be sent.
This assertion is intended to mirror the behaviour of an
informational/performance diagnostic message raised by the D2D debugging
layer.
It seems the D2D diagnostic is raised when the proposed clip region is
aligned to the screen, not to the current transform.
Before this change, the assertion could incorrectly fire when clipping
to transformed rectangles. This could be seen when clicking the
star-shaped buttons in the ComponentTransformsDemo.
With this change in place, the assertion will still fire when e.g.
calling Graphics::reduceClipRegion on a screen-aligned rectangular path,
but will not fire when this path is skewed/rotated etc.
Previously, code such as the following would return a smaller string
width for larger tracking values:
juce::Font f { juce::FontOptions{}.withPointHeight (16.0f) };
const auto g = f.withExtraKerningFactor (1.0f);
const auto a = f.getStringWidth ("foobar");
const auto b = g.getStringWidth ("foobar");
With this change applied, the width 'b' is greater than the width 'a',
as expected.
This reverts commit adc63cecb1.
Reverting this commit is only a temporary measure to facilitate a stable
release of JUCE 8. Further work on this feature will continue on
develop, and will likely be included in a future release of JUCE 8.
The base implementation of this function does nothing, and returns 'not
implemented'. It is more correct to return 'ok', to indicate that
setting the component state succeeded.
If allowAccessToEnclosingDirectory is set to true, it is now possible
for the WkWebView implementation to access sibling files relative to a
file specified with the file:// scheme.
This allows an iOS app to load an HTML file in the documents directory,
and that HTML file can reference and load image files inside the HTML
file's parent directory.
Resizing using window manager functionality (e.g. clicking and dragging
in the non-client area) will send WM_SIZING to the window, which in turn
will enable continuous repainting in the D2D renderer until the resize
operation ends.
Continuous repainting is required in order for the window to display
correctly during the resize. Without continuous repainting, some frames
may not be completely painted, and may display with black areas,
producing a flickery effect.
When a resize is controlled entirely by the client, e.g. using the
corner resizer in the AudioPluginDemo standalone, WM_SIZING is never
posted. Instead, we assume that if the window has captured the cursor
during a setBounds call then it is probably resizing. We enable
continuous repainting in this case, and stop repainting once the window
releases the mouse.
An alternative appropach would be to add some kind of start/stop resize
API to ComponentPeer. I'm currently reluctant to do that because the
ComponentPeer API is already so large.
This change makes it slightly easier to audit invariants of
ModalComponentManager, as we can now be certain that only member
functions of ModalComponentManager can access its data members.
