Reverts commits cea19a9d, 961ff32b, and partially reverts 5ec4d85d
Some issues have appeared on the forums so these commits have been
reverted while the issue is investigated.
In a recent version of Xcode (26.1) release builds would crash the
unittest runner during any tests using a std::vector<char32_t> where
its data was reinterpreted as const CharPointer_UTF32::CharType*.
Similar attempts were made to update the UTF8 a UTF16 tests,
unfortunately avoiding a reinterpret_cast for UTF16 isn't as easy
because CharPointer_UTF16 uses a signed integer type which makes the
test data more awkward to work with.
CGImages created from a juce Image may be drawn after or during
changes to the underlying data. This change copies the required
data into a new buffer to ensure the CGImage data is always
independent from the juce image data.
This fixes an issue where the view would disappear and the window would
become black when the window scene changed, e.g. because screen sharing
was started.
Prior to this commit a Component with setBufferedToImage (true) could
have its image buffer deleted when an OpenGL context was detached. This
meant that this Component continued to be rendered without buffering
even though it was previously requested that it use a buffer.
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.
