Configurable GLESv2 drop shadows

[topisani]

I implemented drop shadows using GLESv2. There is a meson build option to disable them, which leaves the configs and commands in place, but disables the rendering (and thus the GLESv2 requirement).

The shadows are configurable using

shadows.<focused|focused_inactive|unfocused|urgent> <radius> <offset> <color>

Radius is the radius (duh), offset is in the bottom right direction.

It's something that's been requested a few times (#1065, #3380, #1511), and personally i think it really helps the "sexyness" (even though the above screenshot is way over the top).

Currently the main issue is that damage is not being applied when you move a window (especially apparent when dragging floating windows). I assume this should be fairly easy for someone with knowledge of the codebase to fix.

[ascent12]

You should seriously consider telling people of your intentions to do such a PR before you spend a lot of potentially wasted time and effort on it.

For starters, I'm strongly against sway making any GL calls directly; it seriously messes with some stuff going on in wlroots (i.e. the vulkan renderer). Yes, wlr_renderer is stupidly limited, and compositors are free to do whatever the hell they want, but sway is the flagship. If something in wlroots is broken/crap, we fix wlroots instead of making sway work around it.

But also, I think this is fundamentally the wrong way to go about implementing a feature like this. Drop shadows should be implemented as window decorations, rather than a big rectangle behind everything. You can get all of the effects of drop shadows, along with a whole lot more flexibility to do other shit, as well as preventing the situation this may cause with double drop-shadows, where a CSD client draws its own (e.g. GTK).

---

I'm getting off-topic of the discussion of the PR itself here, but this is how I think shadows should be implemented:

If sway had a customizable system for window decorations (which some people have been asking for), you would just clamp something like

to the edges of windows, you can get whatever effect you want, including drop shadows. Technically it only needs to be 1 pixel tall and tile the image all the way along, but I've made it longer just so you can actually see it.
You would need 8 images total, for all of the corners and edges, so you can also have offset shadows. But sway doesn't need to know anything about that, it's just clamping 8 images to the edges/corners.
You would also need some extra information to say what should be considered part of the window geometry and what isn't.

I've been thinking of pitching something like this for inclusion in wlroots as a server-side decorator helper, or possibly as its own library with some kind of "standard" theme system, but it's not something I've actually worked on, and is a low priority on my list of things I want to do. I've also considered a wayland extension which allows the compositor to tell clients what SSDs it should draw, which kind of turns it into a CSD/SSD hybrid, where you get the advantages of both (unified look, but works more nicely with things like direct scan-out).

[ddevault]

Sorry, but I'll pass on this patch.

[topisani]

Makes sense, wasn't really expecting it to get merged, mainly implemented it for personal use. @ascent12 the approach you're describing sounds like it makes more sense, hope we get something like this in the future!

[escalade]

It works and looks great. Hopefully this functionality will be properly added soon.

[WillPower3309]

swayfx currently has rounded corners and shadows, as well as dimming and blur. Fade animations will be next!