Are you using juce::Path or mainly images / groups of components?
The path implementation (as I demonstrated in this thread) doesn’t line up with any modern renderer or design tool. This means people working with vector designs can’t implement them without fiddling around trying to guess how exactly JUCE is broken/different. Then there’s the streaking artifacts…
I imagine there’s many projects out there relying on shadows looking as they do currently, changing that would likely upset many developers
My vote is a documented breaking change to align JUCE with the rest of the world. The devs on this thread spent days/hours working around JUCE to get blurs and drop shadows on paths to work as expected. It would be nice to save that headache for others going forward so that vector designs can be implemented correctly. It seems reasonable to notify devs they’ll need to change a few values on their existing apps when upgrading.
Ahh yeah, I hadn’t considered the inconsistencies with SVGs.
We are using paths but I think possibly the blur radius we’re using is small enough that the difference isn’t that noticeable. Looks like you used 50px in your example above, I believe ours are mostly 5px.
I personally wouldn’t mind the breaking change, I can just imagine the JUCE team would prefer to avoid it if possible. I’m sure there’s many other factors to it that I haven’t considered beyond the fact it might annoy a few people!
OOI did you have any UI scaling enabled with those screenshots? I wonder if the incorrect blur radius is a result of not taking into account the scale factor… just a thought.
Gotcha! Yeah, was wondering if you are implementing designs from something like Figma or illustrator… I’m not using SVGs here, just rendered paths with shadows for depth (no pngs, etc).
We have some bigger 16px shadows but mainly a lot of stacked smaller ones.
did you have any UI scaling enabled with those screenshots?
Nothing explicit! I did cook up that example on my normal retina screen though…
I would also vote for the breaking change and to replace the current JUCE shadow with the faster and popular version.
We are using the current JUCE shadows in our plugins. I think it does not need a lot of work to adjust it to make it look the same. I even don’t care if they look the same. It is often a subtle effect.
My bad, I wasn’t clear enough. I want to apply this technique on my menus, which are based on ComboBoxes. As far as I understood, you take a snapshot of the parent component and then you apply the stack blur on it. Since, as far as I remember, the snapshot needs a rectangle for the aera to be captured, I wanted to try by getting the local bounds of the displayed popup and use that Rect for the snapshot size.
Doing blurs on popupmenus is very hard because you want to do it in the LookAndFeel but the menu methods in the lookandfeel don’t get quite enough information to properly implement this
I’ve recently stitched together the results of various discussions on this forum to create a StackBlur-based blur for juce::Image / juce::Path which is compatible with the expected blur, spread, offset parameters of popular design software. I’m happy to share if others are struggling with this!
well, yeah - I think you should publish it!
(Interested in this whole discussion, but unlikely to attempt all of the experiments discussed. I’d sure like some nifty transparent popups, however…)
I’ve created a pull-request for a StackShadow object, which is mostly related to the problems discussed here:
I really didn’t do much outside of what others on the forum had suggested/already done. Just extended the existing JUCE code to add scaling transforms for spread, and stroked the path and clipped the graphics context for inner shadows.
Thanks for taking the initiative to make a pull request for this!
The implementation could do with some tidying up - looks like it currently follows this old javascript implementation (or one similar) which is not very clean at all. Working through the logical steps and most importantly following the JUCE Coding Standards will surely help it get approved much faster.
I just used what was already available here: GitHub - FigBug/Gin: A few extras for juce as suggested previously and didn’t want to make any changes to that code, but your point is still valid!
