The CONFIG_STACK_CHECK option doesn't work correctly when the QuickJS
engine is initialised on one thread and then later accessed by another
thread, which is a usage pattern implicitly supported by JUCE.
There's a few things going on in this commit:
- The implementation of CharPointer_UTF16 now uses helpers from
CharacterFunctions to avoid a few instances of magic numbers.
- Where it makes sense, member functions of that class have been DRYed
by e.g. implementing getAndAdvance in terms of operator*() and
operator++().
- Added more tests for incrementing/decrementing/dereferencing
CharPointer_UTF16.
After this change, a CharPointer_UTF16 that points to an unpaired
surrogate will always dereference to a 32-bit character with that
surrogate's value.
Note that dereferencing a CharPointer_UTF16 that points to a high
surrogate at the final code unit in a memory region is inherently
unsafe, because CharPointer_UTF16 can't track its own size, and the
dereference operation will check the following code unit to see whether
it is a low surrogate.
This issue presented after the following sequence of steps:
- Display a window with a non-native titlebar
- Maximise it
- Click the taskbar icon to minimise it
- Click the taskbar icon again to maximise it
After being maximised for the second time, the window bounds were too
large for the display. This is because the check in WM_NCCALCSIZE was
failing to determine the target monitor for the window, and therefore
failing to adjust the new area appropriately. We now determine the
target monitor based on the proposed new bounds of the new window,
rather than the current bounds of the window, which may not be
meaningful if the window is minimised.
This reverts commit 3c1012baeb.
This change caused the AudioDeviceManager to open a fallback device if
the device name was empty, the requested number of channels was
positive, and selectDefaultDeviceOnFailure was true.
The new behaviour conflicted with the documented behaviour of
initialise(). The number of input/output channels is to be treated as a
maximum, rather than a preferred count. If a positive channelsNeeded is
requested but the device name is empty, a default device should not be
opened since the actual number of channels (0) is lower than the maximum
specified number.
Fixes an issue where primitives such as text could end up with sharp
edges when creating temporary contexts:
void paint (Graphics& g)
{
g.fillAll (Colours::white);
const auto preferredType = g.getInternalContext().getPreferredImageTypeForTemporaryImages();
Image img (Image::ARGB, getWidth(), getHeight(), false, *preferredType);
{
Graphics g2 (img);
}
g.setColour (Colours::black);
g.setFont (32);
g.drawText ("test", getLocalBounds(), Justification::centred);
}
The important part seems to be initialising the UIWindow directly with
the UIWindowScene, instead of initialising it with a frame and then
assigning a scene later on.
Previously, the elapsed time in nanoseconds was multiplied by 1e6
instead of 1e-6, leading to incorrect timestamps on incoming messages.
This change also DRYs the code handling time conversions between the
native/host time and JUCE timestamps (milliseconds in double format).
- Improve default performance when components check if they are opaque
- Allows all components to take advantage of setPaintingIsUnclipped
- Give more control to opt out of opaque checks separate from setPaintingIsUnclipped
The crash fixed by this commit could be triggered by attaching an OpenGL
context to a component, calling setBufferedToImage (true) on one of its
child components, and then detaching the OpenGL context from the parent.
Since 4ba01a80a0 we are creating images
with the current rendering context's native image type, so the above
scenario would leave an image buffer that references the detached
context.
When clicking in a TextEditor to position the caret, the caret would be
placed at the penultimate position when clicking at the end of a line
with trailing non-newline whitespaces.
Co-authored-by: Aga Janowicz <aga@roli.com>
Newlines get removed in the sanitised string, so we need to take extra
steps to keep track of their positions.
Co-authored-by: Aga Janowicz <aga@roli.com>
On Ubuntu 25.10, which includes Noto Color Emoji, I was seeing that the
FontsDemo would assert when attempting to render non-emoji text using
this font. It appears that FontConfig will tend to return Noto Color
Emoji when this family name is passed, even though the font may not
cover the required character set.
The new strategy is to use FontConfig as before, but then to check the
resolved font for coverage of the string. If the resolved font still
can't render the string, we relax the font matching constraints by
removing the family name from the pattern, then try matching again.
Harfbuzz doesn't support these font formats, so attempting to shape text
using these kinds of fonts will fail.
I noticed this on Ubuntu 25.10 for Arm, which seems to include pfb and
otf versions of some fonts. The FontsDemo would assert in cases where
the pfb font was selected instead of the otf font.
