We’ve been using JUCE’s drop shadow in one of our latest GUI projects, and may be using shadows/blurs more in the future. I can’t say I necessarily agree that “juce’s dropshow is not appropriate for modern UI”.
I found that having a dedicated shadow component for anything that requires a shadow is the way to go (for our particular use case we also needed to be able to specify inner or outer shadows, something JUCE doesn’t really provide a neat API for). Then, by calling
setBufferedToImage(true) on the shadow components, they’ll only be redrawn when their size changes - which for us means they’re only drawn once since the UI is static. If the component being shadowed needs to redraw it’s content, the shadow won’t be redrawn (especially important for us since we have animated level meters being drawn over component with an inner shadow, which themselves are within a panel with an outer shadow).
I spent a while last week trying to implement the Stack Blur algorithm as mentioned above as part of a
juce::ImageEffectFilter. I never managed to get it looking 100% but I did find it to be particularly performant - larger blur radiuses didn’t have much of an impact on performance unlike with the current JUCE blurring implementation (which I believe uses a Gaussian blur).
I don’t think changing the current implementation is the right approach, I imagine there’s many projects out there relying on shadows looking as they do currently, changing that would likely upset many developers. I think the right approach would be to add a new shadow/blur effect, and possibly deprecate the current one.
TL;DR - +1 for adding an implementation of Stack Blur to JUCE.