Previously, drawing an opaque, scaled component with CoreGraphics could
lead to visible artefacts around the edge of the component.
When drawing the parent of an opaque component, the area covered by the
opaque component is excluded from the clip region. If the clip region is
non-integral when transformed into device space, anti-aliasing will be
applied on the edges of the clip region. Similarly, when drawing the
opaque component itself, anti-aliasing will be applied at the edges of
the component. When the two drawings are superimposed, the foreground
anti-aliased pixels will be blended with the background anti-aliased
pixels, leading to a noticeable border around the component. Ideally,
only the foreground anti-aliasing should be applied, and the background
should not be anti-aliased around its edges.
Occasionally, on Linux, Address Sanitizer can complain about a memory
region overlap in the arguments to memcpy, originating in
EdgeTable::intersectWithEdgeTableLine. I haven't been able to reproduce
this personally.
The final memcpy call in this function requires there to be
"srcNum1 * 2" valid entries after the current "src1" ptr, and none of
those entries may overlap with the area starting at "temp".
On inspection, I think that the memory region being read is too large.
At the point of the call, src1 will point to a LineItem::level, not
LineItem::x, so there will actually be (srcNum1 * 2 - 1) valid items
following it.
All this pointer arithmetic is very difficult to understand. In an
effort to make this function slightly more understandable, I've switched
to using Spans to delineate lines of the table, which makes it easier to
keep track of the size of each line.
In cases where there was a static or global instance of a class that
inherited from Timer, due to the order of events when a dll is unloaded
on windows, there was a risk of an infinite hang. Deleting the timer
thread before the dll is unloaded avoids this occurring.
This allows hosts such as Cubase and MultitrackStudio to locate
parameters based on the current mouse position.
Users must override and implement getControlParameterIndex in order for
the parameter to be reported to the host.
The DSPModulePluginDemo shows one possible strategy for implementing
this function.
The bug presented when selecting none for either input or output, when
the opposite input or output was a device that had the same name for
both the input and output
