The FloatVector implementation will be replaced by simd implementations sometime in the future.
I also continue to get these warnings
If you comment on the existing issue and let me know what commit hash you are using, I’ll remember to take a look.
5 Likes
Thanks for this great juce module.
I wonder if it makes sense to add this setBackupEnabled(false) Juce 8 hack, which is needed to get good performance with Direct2D. For the case when the shadow recalculation has to happen on every frame.
juce::Image renderedSingleChannel (juce::Image::SingleChannel, scaledShadowBounds.getWidth(), scaledShadowBounds.getHeight(), true);
{
renderedSingleChannel.setBackupEnabled(false);
Same for the full color image. Maybe it makes sense if we could tell the shadow that it has to recalculate every frame and not use the cache in that scenario.
I’m not sure if there is a way to add this and stay backward compatible with juce 7.
Happy to hear someone else is thinking about this stuff!
When the Direct2D renderer came out, I made a Direct2D GPU branch of the blur that performed significantly better than even the IPP backed CPU Stack Blur variant.
Unfortunately it relied on some internals that have since changed. I’ve chatted with both Matt and Reuben about those details. I just need to find a couple hours to dig back in, get tests and benchmarks happy, test it on my own product before that can get merged in.
RE: backup images, @matt spent some time helping me “get” when a backups should be disabled. From what I understand, it’s really only worth disabling when frequently painting changing content into an image.
So I believe the answer is yes, backups should probably be disabled on Melatonin Blur to help the case when either the blur is recalculating (paths change) or recomposited (color, opacity, etc) due to animation. There’s no actual need for the backup, as we can trivially recreate the content, so we’re not worried about anything being “lost.”
That all being said, I haven’t benchmarked, so I’m not sure the backup’s performance penalty is on the same order of magnitude as a CPU (or even GPU) blur itself. My intuition is that it’s not, but that moving to Direct2D GPU blur is where the real win is.
I’ve been heads down on my own product lately and haven’t been investing as many hours into open-source, but the Direct2D blur is on the list for my own product. I’ve recently been talking with some other companies shipping products with blur out to their customers — it’s clear to me that customers on older Windows CPUs would benefit from a Direct2D blur, especially re: animation.
2 Likes
Thanks for clarifying. It makes sense that the calculation of the blur takes more time than the image copy. I can imagine it could make a difference when you have a huge graphic context and only a small blur.
At the moment, I’m happy with the performance. We also support Linux … I have to make sure the plugin runs well with the software renderer anyway 
1 Like
Gotcha. The module will remain compatible with JUCE 7. The plan is Direct2D GPU blurs would be the new default on JUCE 8 Windows (it’s separate logic from JUCE’s window painting, etc) but there will a macro to opt-out (I’d need it for benchmarks anyway).
1 Like