Wayland-Protocols 1.15 Adds XDG-Decoration Protocol For Server-Side Window Decorations

[tajjada]

Everybody seems to be forgetting the users who use tiling window managers. I want "SSD support" because I *dont want any window borders at all*. I find it really annoying to use Sway in Wayland and have every application draw its huge titlebar on my screen with useless buttons (minimize, maximize) which don't do anything (because they are not applicable to tiling wms). Without this protocol extension, there is no way to turn off titlebars. There is no way to tell the application not to draw a titlebar. This is a big regression in usability compared to i3wm in X11. I don't want to see titlebars, as they are useless to me. I don't "drag windows around". I don't click on buttons on the titlebar. Etc. I would much rather have my extra screen space without unnecessary clutter.

For as long as Wayland was enforcing CSD everywhere, I was staying away from it. I was planning to stick to X11 until this gets fixed.

[oiaohm]

Everybody seems to be forgetting the users who use tiling window managers. I want "SSD support" because I *dont want any window borders at all*. I find it really annoying to use Sway in Wayland and have every application draw its huge titlebar on my screen with useless buttons (minimize, maximize) which don't do anything (because they are not applicable to tiling wms). Without this protocol extension, there is no way to turn off titlebars. There is no way to tell the application not to draw a titlebar. This is a big regression in usability compared to i3wm in X11. I don't want to see titlebars, as they are useless to me. I don't "drag windows around". I don't click on buttons on the titlebar. Etc. I would much rather have my extra screen space without unnecessary clutter.

For as long as Wayland was enforcing CSD everywhere, I was staying away from it. I was planning to stick to X11 until this gets fixed.

Sorry to say there another way to get rid of the title bar and windows boarders. GTK and Qt CSD theme options does support no title bar and no windows boarders options in the theme defines. So both SSD and CSD can do the appearance you want. So it a false claim that there is no off option. Of course this leads back to UI Consistency issue where you are having to set it off for every toolkit.

X11 you can have applications like old XMMS that was client side rendering it tittle bar no matter what. There are other programs like this under X11 that those demanding SSD want to forgot about.

Other than being annoying having the title bar and extra buttons taking up screen space its fully functional right. SSD on the other hand in a CSD environment like X11 server without a windows manager is not that functional at all.

SSD and CSD you fairly much are turning stuff off in the same kind of places most of the time. I will say CSD does need more UI Consistency issue fixing so QT/GTK and other toolkits have a unified format to read to work out what they should do about windows boarders and title bars. Of course UI Consistency need to also go into buttons and checkboxs and other parts as well.

Transparency and shadows effects are the things CSD under wayland would be pushing up hill todo. Just wanting to turn interface features off that is just theme settings. Yes you can have a SSD windows manager that has a theme on say it will draw those title bars and buttons you don't want as well.

Remember its impossible to do Transparency client side with wayland due to applications without special permission being able to see contents of screen so unable to see the stuff behind the application window.

Yes the idea you need SSD support todo tiling windows managers correctly is bogus.

[M@yeulC]

Sorry to say there another way to get rid of the title bar and windows boarders. GTK and Qt CSD theme options does support no title bar and no windows boarders options in the theme defines. So both SSD and CSD can do the appearance you want. So it a false claim that there is no off option. Of course this leads back to UI Consistency issue where you are having to set it off for every toolkit.

X11 you can have applications like old XMMS that was client side rendering it tittle bar no matter what. There are other programs like this under X11 that those demanding SSD want to forgot about.

Other than being annoying having the title bar and extra buttons taking up screen space its fully functional right. SSD on the other hand in a CSD environment like X11 server without a windows manager is not that functional at all.

SSD and CSD you fairly much are turning stuff off in the same kind of places most of the time. I will say CSD does need more UI Consistency issue fixing so QT/GTK and other toolkits have a unified format to read to work out what they should do about windows boarders and title bars. Of course UI Consistency need to also go into buttons and checkboxs and other parts as well.

Transparency and shadows effects are the things CSD under wayland would be pushing up hill todo. Just wanting to turn interface features off that is just theme settings. Yes you can have a SSD windows manager that has a theme on say it will draw those title bars and buttons you don't want as well.

Remember its impossible to do Transparency client side with wayland due to applications without special permission being able to see contents of screen so unable to see the stuff behind the application window.

Yes the idea you need SSD support todo tiling windows managers correctly is bogus.

I am sorry, I do not exactly see it that way. Of course, you can change settings for each and every toolkit out there (if they support it). But this necessarily will lead to a sub-par experience, as you have to either launch an application one time, or edit a config time ahead of time.

The only viable option is a shared place among the toolkits to write this preference to. This could have been an environment variable as well; but the rightful place is obviously the protocol itself, that handles every other tiny detail.

Bottom line is that you don't want an application to draw window decorations where they are not needed, and that's all that count: tiling WM, fullscreen WM (like the ones of in-vehicle entertainment, phones, TVs, etc), or inside of other window decorations. Having a way to tell the toolkit exactly this is important, regardless of their technical merits.

---
Now, on technicalities:
I personally don't do any distinction between compositor and window manager, even under X. That might be a mistake, but that entity could be a black box or a set of even more components; and it wouldn't change a thing.

Transparency can be handled client-side trough RGBA buffers, with the compositors doing the blending (likely on the GPU).

I don't see why the compositor couldn't render the whole window with its borders to a buffer, and use that when dragging it around? This will likely be hardware-accelerated texture painting, anyway, so it should be a virtually zero cost increase. As for scheduling that someone mentioned elsewhere in the thread, I am no compositor specialist, but I expect that the compositor needs some CPU time at each frame, to do the actual compositing and buffer flipping, so there is no reason why SSD would be less responsive (since the app takes less time rendering, and the compositor a bit more). Actually, you even reduce the area to repaint if no resizing happened, so it could be negligibly faster/more energy-efficient, depending on the assumptions of the app/compositor.

Resizing is a bit more of an issue, but it shouldn't be any different for SSD than CSD: resize window -> resize buffers (draw decorations if SSD) -> pass buffer to application for rendering -> application renders (draw decorations if CSD).

(assuming the buffers are correctly mapped, no extra round-trip to the compositor might be needed, I'm not an expert). I don't see any performance difference? Am I missing something?

---
On the usual argument CSD vs SSD: this is a matter of viewpoint, but I see for example the android UI as SSD, and the expectation that applications do not draw any borders by default sounds like something sane to me for most environments, applications and developers, as it seems to minimize developer effort for almost all parties (but SSD toolkits, that already spend some extra effort drawing their decorations, so it would be part of it).

---
To summarize: you don't need to worry about window decorations for tiling window managers, as you said*. But by the same account, the idea you need CSD (or SSD) for non-tiling WM is completely bogus as well. You don't *need* window decorations at all, period (alt drag, alt click for example, perform operations trough your task manager). But that wouldn't play nice with what those non-tiling WMs are trying to look/feel like (the same can be said to counter the argument for CSD in tiling WM). So please stop downplaying other use cases; that would just be lobbying for your own use case (which might change with time, btw). There are only upsides in empathically considering the viewpoint of others.

*Though I would expect someone who uses a tiling WM not be extremely happy with some extra clicky-button

[Weasel]

@oiaohm: I'm not sure how to say this any easier for you to understand. All I see when you talk about CSD is "blah blah GTK blah blah Qt blah blah GNOME".

I'd like for you to do an experiment: picture a world and userland where I don't want to use stinking GTK or these toolkits. Yet, I want to keep a unified decoration. Can you picture such a world?

Good, now argue for CSD in this world because to me your GTK/GNOME is getting on my nerves when I don't want to rely on those shits to provide my unified theme for apps. Do you get it or I have to repeat it 1000 times?

It's clear as day at this point you're a GNOME fanboy anyway and I know that's what they love to force their crap down people's throats but you aren't convincing me unless any argument completely removes the words GNOME or GTK from it.

[Gusar]

oiaohm: I don't plan to ever use Mutter so I don't care one bit whether they'll add support for this protocol or not. But they're only hurting their own users if they don't. For example, before mpv disabled wayland by default (so it'll run with Xwayland unless you explicitly request native wayland), there was a constant stream of "mpv doesn't have borders" reports from Gnome users. So now Gnome users get degraded performance (the overhead of Xwayland) when using mpv, but hey, Gnome knows best, right? And no, arguing that mpv should link to GTK or some other toolkit just for borders is not the way to go. It's ridiculous that a DE-independent and toolkit-independent application should be forced to link to a big toolkit just to draw borders. SSD is the proper solution. A protocol for them now exists, because clearly I'm not the only one who holds the view I'm expressing here. So now it's on Gnome devs whether they want their users to have a good experience or whether they'll stubbornly cling to their own thing to the detriment of their users.

[renox]

I don't really understand this push for CSD on Wayland, the modern way of displaying windows is with shadows, right?
So if the application render itself fully then it should render also the shadows but sometimes the shadows are clipped something that the window compositor knows but not the application, so those saying that SSD use more resources than CSD.. Well it depends..
Even without shadows, if you have "security levels" like QubeOS do, this client-side decoration isn't the real decoration as the window manager wraps your window with a border to indicate its provenance and security level..

[Weasel]

oiaohm: I don't plan to ever use Mutter so I don't care one bit whether they'll add support for this protocol or not. But they're only hurting their own users if they don't. For example, before mpv disabled wayland by default (so it'll run with Xwayland unless you explicitly request native wayland), there was a constant stream of "mpv doesn't have borders" reports from Gnome users. So now Gnome users get degraded performance (the overhead of Xwayland) when using mpv, but hey, Gnome knows best, right? And no, arguing that mpv should link to GTK or some other toolkit just for borders is not the way to go. It's ridiculous that a DE-independent and toolkit-independent application should be forced to link to a big toolkit just to draw borders. SSD is the proper solution. A protocol for them now exists, because clearly I'm not the only one who holds the view I'm expressing here. So now it's on Gnome devs whether they want their users to have a good experience or whether they'll stubbornly cling to their own thing to the detriment of their users.

Amen.

I made a post but it seems it got eaten?

oiaohm : I don't know how to tell you this but before I consider your arguments all I see is first "blah blah GNOME blah blah GTK blah blah GNOME". You know what that means to me? Worthless argument.

To help you understand, imagine a world where the user doesn't use GNOME and his app doesn't use GTK, and still wants a sane decoration that fits his desktop theme. Can you imagine such a world? Stop shoving GNOME down on people, I know you're a gnome fanboy, but some of us do NOT want to use it or toolkit for an app just to have borders or other features that Wayland lacked (or still lacks?). Period.

If you want to convince people of the benefits of CSD, do it without using the words GNOME or GTK in your post, because otherwise it means nothing.

[oiaohm]

I am sorry, I do not exactly see it that way. Of course, you can change settings for each and every toolkit out there (if they support it). But this necessarily will lead to a sub-par experience, as you have to either launch an application one time, or edit a config time ahead of time.

The only viable option is a shared place among the toolkits to write this preference to. This could have been an environment variable as well; but the rightful place is obviously the protocol itself, that handles every other tiny detail.

Bottom line is that you don't want an application to draw window decorations where they are not needed, and that's all that count: tiling WM, fullscreen WM (like the ones of in-vehicle entertainment, phones, TVs, etc), or inside of other window decorations. Having a way to tell the toolkit exactly this is important, regardless of their technical merits.

UI Consistency says that interface appearance settings should have a unified space be it SSD or CSD. The reality is those doing in-vehicle have been doing full screen with windows effects turns off by altering the theme file so using normal CSD.

ITransparency can be handled client-side trough RGBA buffers, with the compositors doing the blending (likely on the GPU).

The inability to see background data means means fine tuning of the RGBA cannot be done client side. Yes transparency can be partly done client side but there is a issue here. SSD side that is meant to have access to the final rendered desktop can run compare checks to make sure details of the window have not blended straight into background. This is not a problem you run into in insecure X11.

As for scheduling that someone mentioned elsewhere in the thread, I am no compositor specialist, but I expect that the compositor needs some CPU time at each frame, to do the actual compositing and buffer flipping, so there is no reason why SSD would be less responsive (since the app takes less time rendering, and the compositor a bit more).

So close. Lets do a very rough theory scheduler a basic fair round robin.. Compositor doing a little more can be a problem.
Lets say the scheduler is in fact handing out cpu evenly. So you have 9 applications and the compositor. Each one gets 1/10 of the cpu time. CSD is spread over all the processes fairly evenly so coming out the 1/10 of cpu time for the application and the compositor gets to use its 1/10 to perform compositing operations only.

Remember now doing SSD. Even cpu give out means the compositor is only going to get 1/10. Now in SSD all the window boarder and title bar modifications are having to be done by the compositor applications are still getting there 1/10. Now what happens if rendering the application windows decorations exceeds the SSD compositors time slice of 1/10 because someone used a complex theme. The result is stall because if the compositor does not complete it tasks inside it allocated time slice it will have to wait for the scheduler to cycle past all other applications before its more cpu time to go on in a round robin set up.

SSD to function stable will be depending on scheduler bias. Also think about case application goes nuts creating windows. In CSD application will be limited by its own CPU time slice allowance so less able to dinal of service attack the compositor.

SSD is at high risk of stalling due to eating itself out of it allocated cpu time. CSD is likely to have bad behaving CSD program freeze individually before the CSD compositor shows issue.

Actually, you even reduce the area to repaint if no resizing happened, so it could be negligibly faster/more energy-efficient, depending on the assumptions of the app/compositor.

Reducing area of repaint can be done CSD. The work that being done in opengl and vulkan memory optimisations to prevent copying only minor modified buffers.

Resizing is a bit more of an issue, but it shouldn't be any different for SSD than CSD: resize window -> resize buffers (draw decorations if SSD) -> pass buffer to application for rendering -> application renders (draw decorations if CSD).

To be properly secure normally application render has to happen before SSD decorations are applied. Commonly SSD decorations have end up stored in a buffer that stuck behind the client buffer by the GPU.

(assuming the buffers are correctly mapped, no extra round-trip to the compositor might be needed, I'm not an expert). I don't see any performance difference? Am I missing something?

Remember SSD is sold as secure. Result of secure is the windows decorations end up in their own buffer. This is what increases you memory usage of SSD.

On the usual argument CSD vs SSD: this is a matter of viewpoint, but I see for example the android UI as SSD, and the expectation that applications do not draw any borders by default sounds like something sane to me for most environments, applications and developers, as it seems to minimize developer effort for almost all parties (but SSD toolkits, that already spend some extra effort drawing their decorations, so it would be part of it).

Yes Android is SSD and it does suffer from issues. You will notice android on phones and tablets attempts to run full screen as much as possible to avoid having to render any window decorations. Avoids the time slice problems.

To summarize: you don't need to worry about window decorations for tiling window managers, as you said*. But by the same account, the idea you need CSD (or SSD) for non-tiling WM is completely bogus as well. You don't *need* window decorations at all, period (alt drag, alt click for example, perform operations trough your task manager). But that wouldn't play nice with what those non-tiling WMs are trying to look/feel like (the same can be said to counter the argument for CSD in tiling WM). So please stop downplaying other use cases; that would just be lobbying for your own use case (which might change with time, btw). There are only upsides in empathically considering the viewpoint of others.

CSD with libinput support in wayland in theory allows wayland applications to go on after tiling windows manager has crashed. This is why CSD so that if you can build in resistance compositor crash and allow applications to keep on rendering you see the CSD appear and you know things have gone badly wrong.

Remember if application is updating its CSD buffer and the compositor is dead what was left configured in the GPU can still be rendering those CSD buffer changes to screen. CSD is a good position for applications to attempt to fail safe to.

oiaohm: I don't plan to ever use Mutter so I don't care one bit whether they'll add support for this protocol or not. But they're only hurting their own users if they don't. For example, before mpv disabled wayland by default (so it'll run with Xwayland unless you explicitly request native wayland), there was a constant stream of "mpv doesn't have borders" reports from Gnome users. So now Gnome users get degraded performance (the overhead of Xwayland) when using mpv, but hey, Gnome knows best, right? And no, arguing that mpv should link to GTK or some other toolkit just for borders is not the way to go. It's ridiculous that a DE-independent and toolkit-independent application should be forced to link to a big toolkit just to draw borders. SSD is the proper solution. A protocol for them now exists, because clearly I'm not the only one who holds the view I'm expressing here. So now it's on Gnome devs whether they want their users to have a good experience or whether they'll stubbornly cling to their own thing to the detriment of their users.

Exactly why cannot mpv just render a boarder of it own. Like xmms and other things have done in the past. Heck OSC of mpv did that in the past as well.

Really its ignoring that CSD was always X11 fall back mpv use to support that in recent years lost that feature as dependable. Yes running mpv without a windows manager with X11 by itself use to be quite good. What else should I expect from a person backing a broken X11 application it can stay under X11.

SSD is not a proper solution in all cases. SSD has serous downside.

The reality is gnome users can use gnome-mplayer and have CSD wayland support.

Really MPV is a poor example when you know it use to support CSD X11 and it does not support that now. MPV a broken application that need to be fixed back to it former feature set and if it was fixed back to it former feature set it should not be having problems with wayland. Ok not blend in but as a fall back for when SSD is missing would be good enough.

Gusar I guess you were not aware that MPV toolkit historically contained the features to render it own boarders on X11 so it could run without windows manager.

[oiaohm]

Amen.

I made a post but it seems it got eaten?

oiaohm : I don't know how to tell you this but before I consider your arguments all I see is first "blah blah GNOME blah blah GTK blah blah GNOME". You know what that means to me? Worthless argument.

To help you understand, imagine a world where the user doesn't use GNOME and his app doesn't use GTK, and still wants a sane decoration that fits his desktop theme. Can you imagine such a world? Stop shoving GNOME down on people, I know you're a gnome fanboy, but some of us do NOT want to use it or toolkit for an app just to have borders or other features that Wayland lacked (or still lacks?). Period.

If you want to convince people of the benefits of CSD, do it without using the words GNOME or GTK in your post, because otherwise it means nothing.

Reality here I have said theme system need to be fixed up many times. CSD has it technical advantages.

So boarder of his application blends in kind of with the desktop but his applications has like a black inside and a pink border because its not using desktop theme so looks totally horrible. Get the point yet your application doing its own title bar and boarders and not blending in properly really does not alter the fact it was not going to blend in properly in the first place.

UI Consistency issue hurt you be the application CSD/SSD. So if application internal is not using the desktop theme its title bar and boarders might as well not either. So its title and boarders don't look completely stupid on it.

Basically Weasel you made a UI Consistency arguement like normal is not based on fact. The reality is it going to cause extra code to have to be added to application to render title bar and boarders so application developers will not be able to forgot the fact they are not blending into the desktop properly. Maybe then developers will start working on a proper theme system and get proper UI Consistency.

Basically I don't care if application uses GTK or GNome. From my point of view QT, GTK, Wxwindows... what ever toolkit application should at least look reasonable the same when someone applies a theme. Currently they look like a complete mess. SSD only part fixes the window decorations but what about all the other toolkit decorating that end up completely wrong and in a mess. Only way to fix this is get a proper theme system that all toolkits use. This would solve the CSD problem as well as applications rendering their own boarders would have someone to look up how their window should look..

[Weasel]

Lets say the scheduler is in fact handing out cpu evenly. So you have 9 applications and the compositor. Each one gets 1/10 of the cpu time. CSD is spread over all the processes fairly evenly so coming out the 1/10 of cpu time for the application and the compositor gets to use its 1/10 to perform compositing operations only.

Remember now doing SSD. Even cpu give out means the compositor is only going to get 1/10. Now in SSD all the window boarder and title bar modifications are having to be done by the compositor applications are still getting there 1/10. Now what happens if rendering the application windows decorations exceeds the SSD compositors time slice of 1/10 because someone used a complex theme. The result is stall because if the compositor does not complete it tasks inside it allocated time slice it will have to wait for the scheduler to cycle past all other applications before its more cpu time to go on in a round robin set up.

SSD to function stable will be depending on scheduler bias. Also think about case application goes nuts creating windows. In CSD application will be limited by its own CPU time slice allowance so less able to dinal of service attack the compositor.

SSD is at high risk of stalling due to eating itself out of it allocated cpu time. CSD is likely to have bad behaving CSD program freeze individually before the CSD compositor shows issue.

Or just multi-thread the compositor?

You know... like a proper server... cause that's what it is.