Should shadows and rounded corners be implemented in gala instead?

[pushqrdx]

I like how the new odin style goes for a slightly rounded corners on the whole window, However the effect is broken because of gtk, so Firefox for instance only has rounded top corners, many other none elementary GTK apps suffer from the same issue. So i was wonder would it be more reasonable and controllable to remove the shadows/rounded corners from the stylesheet and implement both of them in Gala? This will have the following benefits

1. Control over how shadows are blended, which will make Blend mode that increases saturation under areas of low value #946 possible
2. Given that the radius that elementary is going for isn't ridiculously big, all windows will have rounded corners making the desktop feel a lot more consistent
3. If the user decides to use any other stylesheet other than elementary's we can simply turn off shadow/rounded corner in gala. So we don't interfere with GTK rendered shadows/corners
4. Globally controllable shadows, like disabling shadows all together.

Just wanted to present the idea and hear people's opinion about it, what do you think might be disadvantages to this approach and/or do you agree that it would make for a nice improvement

[cassidyjames]

As far as I understand, we can’t reliably do this in the window manager. There is a similar discussion on the Mutter issue tracker. Since we rely on Mutter as our window management library, we’ll defer to them.

https://gitlab.gnome.org/GNOME/mutter/-/issues/1517

[pushqrdx]

not in the window manager but in the compositor, shadows and round corners can be composited by gala. Also what i see there is a debate and some people thinking it's about CSD vs SSD which isn't the point of the poster, the point is that shadows shouldn't probably be the responsibility of the toolkit/window but the window manager and/or the compositor that puts them together, which in the end results in a more cohesive desktop

[davidmhewitt]

Gala is the compositor and the window manager, so I think Cassidy is using the terms interchangeably here.

CSD and SSD are also very relevant to this discussion. With CSD, I can draw a window that's a perfect circle if I want to and I can make it draw its own (circular) shadow around itself. Because it's CSD, the window manager knows not to draw any decorations and this all works great.

The first problem comes when we realise that the compositor "sees" all windows as rectangles, even if the window that you see is not rectangular. So, it follows that by default, the compositor could only draw rectangular shadows. So in our circular window example above, we have a circular window with a circular shadow, that the compositor then draws a rectangular shadow around because it doesn't know any better.

Again, you might think we could do some clever tricks like detecting transparent pixels within the window and using that to determine where the "window border" is and draw the shadow around that. But then you have to start considering windows that have transparency as a style thing like transparent/semi-transparent terminals. And doing stuff like that would be quite the performance hit for little gain.

What would also be required here is some method of telling all windows not to draw their own shadows or round their own corners, which might be possible for GTK apps. But other applications from x number of other toolkits/frameworks always come along and break the pattern.

So in an ideal world, where all windows from all applications don't have funky shapes, have perfectly rectangular corners and don't draw their own shadows, it may be possible to have the compositor handle the rounded corners and the shadows, but given the current technologies and limitations, we already have the best we can do.

[pushqrdx]

@davidmhewitt

The first problem comes when we realise that the compositor "sees" all windows as rectangles

All you have to do to get a window shaped shadow is use the same (as window) vert buffer to create a texture, set it to zero (black) and blur it, which will give you a shadow even for a star shaped window, I don't really see why you think that the compositor has to do any more calculations there. It can even be generated very quickly on the gpu

which might be possible for GTK apps. But other applications from x number of other toolkits/frameworks always come along and break the pattern.

Yeah this is an issue of course, but afaik qt apps don't do this, and gtk apps can be overridden so that they don't draw shadows themselves. But of course we still have to worry about enlightenment and other niche toolkits that might break but i see that it's a fair exchange, either way different toolkits are already breaking everything, for instance the whole situation with QT styling vs GTK styling, vs enlightment styling.