The OpenGL renderer listens for imageDataChanged() to invalidated cached
textures.
Before this change, the SimpleFFTDemo would display a static (outdated)
image on Windows when using the OpenGLRenderer.
When syncing from CPU->GPU storage, we currently copy the entire image
contents. The contents of the CPU backup completely replace the old GPU
image. Therefore, if any pixels need to retain their existing values, we
need to read those pixels before overwriting them. This in turn implies
that, when a BitmapData refers to a subsection of the image, we should
always flush GPU->CPU storage first, so that the subsequent CPU->GPU
sync doesn't clobber pixels outside of the BitmapData region with
outdated values.
It's clear that copying the entire image back and forth could be
suboptimal when writing to image subsections, but to optimise this
process we'd have to keep track of dirty image regions or similar, which
may in turn pessimise more common cases.
With this change in place:
- The compatible VST2 ID will be included in the list of compatible
classes in the moduleinfo.json.
- getCompatibleParameterIds() will be called with the ID of the
commpatible VST2 plugin.
In the DemoRunner, switching to and fro between the Settings tab and
the Demo tab displaying the OpenGL demo could lead to
GL_INVALID_OPERATION errors. This is because closing the demo shuts
down the GL context, destroying resources such as framebuffers. If any
Image objects backed by framebuffers outlive the context, they will be
invalidated. Component effect images are especially likely to hold onto
invalid framebuffer references.
With this change in place, images cached by Components will be
invalidated when the attached GL context goes out of scope, and will be
recreated when the new context is created.
Previously, this code assumed that a single channel image would always
have a pixel stride of 1. For image types where this assumption did not
hold, such as OpenGL, this function would produce incorrect results.
JUCE convention is that BitmapData holds the lines of the image ordered
from top to bottom, but OpenGL orders lines in the reverse direction.
By returning a negative line stride, we can iterate lines in the
expected order as long as we always increment the current pointer
position by the line stride after processing each line.
Fixes a regression introduced in
bd26d79b17
The issue was observed in the DemoRunner when enabling the OpenGL
renderer and then switching to the LookAndFeel V1.
The cause of the problem was the creation of a secondary OpenGL-backed
Graphics instance in the DropShadowEffect. This temporary context could
modify the OpenGL context state without restoring the state
appropriately on destruction. As a result, when the outer long-lived
OpenGL context resumed drawing, properties such as the viewport, bound
shader, shader uniform values, and bound framebuffer could all be
incorrect.
OpenGL contexts normally can't be nested. Previously, when the main
renderer for the DemoRunner was set to OpenGL, we would forcibly reset
the engine to the software renderer when displaying any heavyweight
demo, including the OpenGL demos.
19061e6d introduced a regression, where the rendering engine was no
longer reset on Windows, so displaying an OpenGL demo while the global
renderer was also set to OpenGL would cause an assertion to fire in the
OpenGL Graphics context, after which rendering would fail.
With this change in place, we now fall back to the Direct2D renderer,
instead of the software renderer, when displaying a heavyweight demo.
Prior to this commit the returned values were always normalised to the
value returned by getHeightInPoints().
I.e. getAscentInPoints() + getDescentInPoints() would always equal
getHeightInPoints(), even if ascent or descent overrides were in place.
With this change in place getAscentInPoints() + getDescentInPoints()
will always equal
getHeightInPoints() * (getAscentOverride() + getDescentOverride())
JUCE classes don't use this value for layout logic, so this commit
causes no visible changes in how JUCE draws text.
This commit removes the possibility to construct BidiParagraph and
BidiLine objects with non-zero offsets. We don't use these features,
and the assumption that these offsets are always zero simplifies our
visual ordering algorithm.
Prior to this commit we overallocated the s32 buffer. The buffer was
unnecessarily padded by zeros, and the line stating this, wasn't
actually dropping the null terminator.
After reviewing the NSAttributedString API it seems justified to have
two different functions for additive and multiplicative line spacing
settings. For NSAttributedString they are setLineSpacing and
setLineHeightMultiple.
Using this function, when appropriate, exercises it lessening the
likelihood of code rot.
This makes Direct2DMetrics and current frameId accessible to implementation subclasses.
It also replaces JUCE_WRITE_TRACE_LOG with JUCE_WRITE_TRACE_LOG_VA as intended in original implementation.
Co-authored-by: Matt Gonzalez <matt@echoaudio.com>
