This idea is to give the flexibiliy for a Drawable and the SVG parser to support the filter element tag. More details here.
One method would be to extend Component::setComponentEffect to allow ownership of the pointer, and this would open the door to extending the SVG parser to set the filter effect as provided.
Currently setComponentEffect is a JUCE pitfall that should be removed. It makes drawing slow.
If JUCE switches to effects supported by the native drawing APIs, or switches to draw everything including the effects with the GPU/Vulkan, then it won’t be a pitfall anymore.
Oh yes, I totally agree. I was simply offering a solution within the current lay of the land! “Make rendering less weird and less pixel focused” is its own FR.
Rather than adding these features piecemeal to the SVG renderer perhaps it makes more sense to request cairo or nanovg integration, both of which pass meaningful portions of the SVG conformance test suite. Or to improve the webview support.
I’ve stopped using SVGs in JUCE projects altogether because it’s impossible to get them to look equivalent to whatever Sketch/Adobe/Chrome renders. Other libraries are better tested and supported.
Totally fair to suggest not using JUCE because of the holes… Though pointing out the big holes is part of the motivation, so as to deter people from using this lackluster solution.
As you said, it’s better to completely brush the provided SVG parser aside for an existing compliant and open source alternative.
On the bright side, I’m taking this as an opportunity to learn more about the specs and what goes on under the hood with JUCE.
In terms of the filters feature, it’s pretty unnecessary. The rest would be useful though, as I’ve encountered so many issues (along with designers I’ve worked with) over the years when trying to wrangle JUCE’s parser into submission - all to ignore it for images or drawing in code.
To be fair, JUCE’s gradients look far better than existing solutions - what with the gamma correction and blending being sexy as frig.