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

[Gusar]

Heck OSC of mpv did that in the past as well.

No it didn't.The mpv OSC is drawn inside the video window, that's always been the case and it's impossible for it to be drawn elsewhere. That's because the OSC is effectively a subtitle, it's a libass (a subtitle library) rendering. Yeah, mpv is abusing a subtitle library for its internal GUI, it's just that hardcore of an application .

Really its ignoring that CSD was always X11 fall back mpv use to support that in recent years lost that feature as dependable.

I don't know what you think you remember, but your memory is faulty. mpv never had any kind of internal border rendering support.

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

I specifically mention advocating linking to a big toolkit is not the way to go, but here you are, advocating exactly that. Well, you're advocating using a GTK frontend for mpv, but that's not much different. Bravo sir, you win the internets .

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.

There is no "MPV toolkit". mpv is effectively a very low-level application that interfaces with the windowing system directly (actually, it doesn't even need a windowing system. it can run on KMS/DRM directly, with full hardware acceleration!). And it was never able to draw its own borders - if you're so sure that it did, please point to the git commit that removed this functionality. (hint: you won't find it)

What else should I expect from a person backing a broken X11 application it can stay under X11.

Yes, that's the perfect way to treat users - arrogant talking-down-to and calling applications "broken". And actively encouraging users to _not_ use Wayland. Brilliant .

[Weasel]

Yes, that's the perfect way to treat users - arrogant talking-down-to and calling applications "broken". And actively encouraging users to _not_ use Wayland. Brilliant .

Sounds like perfect GNOME camp behavior to me, nothing new here.

[oiaohm]

Or just multi-thread the compositor?

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

Except that does not fix the scheduler problem. The 1/10 is because scheduler can be slicing cpu and IO time evenly across processes. Note I said processes items with direct PID numbers adding more threads is just slice that 1/10 up into smaller bits not get more on particular schedulers..

Even adding more processes as proper servers find out inside cgroups does not mean that you will get any more cpu time from the scheduler.

A lot of proper servers that long term have been on Linux/Unix are multi process not multi-thread as this gives the best chance of getting more cpu time without having to tweak the scheduler. CSD has some pain but on complexity is fairly simple way to spread the load over multi processes..

I don't think coding a compositor as multi process is going to be that fun but its been done.

Durden from Arcan party you use pushing for SSD theirs is multi process not multi thread. Yes it wrapping each application under a individual process so the main compositor can crash/restart and applications keep on running. You might as well make a thin wayland on wayland compositor and use that for SSD applications it going to be just as heavy. This is why I said the Arcan post is kind of bias they skip over why it works for them. SSD works for Aracn because its a multi process beast and fairly resource hungry.

CSD advantages is when you are resource restricted. Think about it you have CPU restricted a particular application. Under CSD that restricted application naturally has reduced compositor work load as it taken care of it client side decorations. If you are targeting light hardware you will be wanting applications to do their own decorations.

Please note some of Arcan arguments about improved shaders and the like in gpu does not apply since graphics cards are growing shared shader caches so that been deduplicated anyhow. Of course arcan does not mention they are doing Durden SSD multi process any how and is also depending on those shared shader caches..

[oiaohm]

I don't know what you think you remember, but your memory is faulty. mpv never had any kind of internal border rendering support.

I thought mpv came out of one particular mplayer fork that had xmms skin support. If it had that it would have the means to render borders. But it does not this was a memory mistake and what they called their system was OSD. I typoed one letter and mixed up where mpv came out of mplayer forks.

I specifically mention advocating linking to a big toolkit is not the way to go, but here you are, advocating exactly that. Well, you're advocating using a GTK frontend for mpv, but that's not much different. Bravo sir, you win the internets .

The reality here is end users have choice of gnome-mplayer. Due to mpv being broken on wayland its choice users are being sent.

This is not be advocating this is what happens when program is broken.

Yes, that's the perfect way to treat users - arrogant talking-down-to and calling applications "broken". And actively encouraging users to _not_ use Wayland. Brilliant .

Mpv developers are arrogant attempt to claim their program is not broken and the desktop has to support something.

To a user they load up Mpv on wayland CSD compositor it has no windows borders it broken. They load up gnome-mplayer it has borders so it working.

If MPV had the code for skin from the mplayer branch that support XMMS skins user load application it appears with borders different to the rest of the desktop and the user can choose stuff it I don't care that it looks different. They don't go try other applications. They don't create risk of a new fork.

KDE developers in the protocol for SSD have include the means to request application switch from SSD to CSD. Why is this. Lets say for some reason the part of the KDE desktop compositing system that does SSD need to be restarted. Kind of useful to be able to ask applications to take care of their own decorations while that is done.

MPV developer have the point of view its only those using gnome with the problem. Its not. KDE desktop having trouble MPV not having a CSD fall back is a problem.

CSD as fall back does not have to perfectly match everything else on the desktop. In time CSD veneration application to application could be addressed if UI constancy issue is addressed.

Something serous to take note of. Claiming a CSD wayland compositor is broken because it does not support SSD so program does not work right does not fly when you have a front end/competitor offering same features that works end users. End users will not class the wayland compositor as broken but the application who front end/competitors do work but the application does not is broken.

Please note my define of working does not mean blend in perfectly with desktop. Provide the general expected window border interface that colour matches to your application interface and your are done. So with mplayer you would make border part of its interface skin.

Also the increase number of wayland bug reports tell you more and more users are using wayland desktops.

Really I don't see why I should treat application kindly and not call them broken when that is what the users of them will call them.

[Gusar]

Really I don't see why I should treat application kindly and not call them broken when that is what the users of them will call them.

Because users can't possibly be wrong?

[carewolf]

Or Gtk apps on Plasma?

No, that has always worked and will continue to work but look odd since client side decoration are still around and allowed.

[starshipeleven]

Because users can't possibly be wrong?

For those that didn't get this: users don't know shit and blame random things.
Like saying that systemd broke their mdadm RAID.

Or that their PC is full of evil spirits.

Same thing.

[Weasel]

CSD advantages is when you are resource restricted. Think about it you have CPU restricted a particular application. Under CSD that restricted application naturally has reduced compositor work load as it taken care of it client side decorations. If you are targeting light hardware you will be wanting applications to do their own decorations.

Honestly this is a thing that 99.99999999% of users, even on servers, don't give a shit about, so I'll just ask... who cares?

No, really, who cares about reducing the application's drawing processing? I understand making a computing-intensive app with lower priority or reduced work load... not drawing its damn borders.

What's next, disable hardware acceleration in the app because it can lock up your GPU with some commands and driver bugs? (oh wait, the "security" extension in Xorg actually does do this, pathetic and it's the reason nobody uses it, I wonder why Wayland doesn't follow it, having hardware acceleration enabled is a "huge" threat to security and denial of service omg!).

This kind of denial of service -- from a local app -- is the biggest pseudo security babbling ever.

[oiaohm]

Because users can't possibly be wrong?

In this case users point of view is important one.

https://www.phoronix.com/scan.php?page=news_item&px=GNOME-3.30-Mutter-X11-Relief

The idea that Mutter needs SSD for X11 support is going straight out the window. Since Mutter may be running with X11 disabled.

So MPV work around of us X11 because they don't have CSD of some form is going to fail. Result is of course users will have to use their alternatives.

Honestly this is a thing that 99.99999999% of users, even on servers, don't give a shit about, so I'll just ask... who cares?

No, really, who cares about reducing the application's drawing processing? I understand making a computing-intensive app with lower priority or reduced work load... not drawing its damn borders..

The thing where CSD comes important is not computing-intensive app with lower priority but in fact computing-intensive app with high priority like a game. In fact at times when it higher priority than the compositor. So the compositor can be quite cpu time staved.

Yes having a compositor render SSD for applications on really low priority might be a good thing. Of course this is when the compositor it self has adequate slice of cpu and gpu to-do this.

Users have been complaining about all X11 wm managers at times causing interface stalls when they make applications have high priority and stave the wm/compositor for cpu time.

So that 99.99999999% is normal weasel garbage. Bug reports tell you its way higher than that.

CSD reduces the workload compositor need to do so more cpu time can be allocated to like the foreground application. As the bias like this staves the other applications that are not the high priority application user wants redraws to the compositor from them slows as well.

Computing-intensive app giving low priority having to draw its own borders so that compositor has less workload so the Computing-intensive app that is giving high priority has more over of cpu time is more what users want in performance.

Problem here is cpu time is a limited resource that has to be sliced up by the scheduler. Depending on how the cpu time is being sliced up effects if SSD or CSD is better. If compositor has plenty of cpu time doing SSD is ok. If compositor is short on cpu time being able to tell application to CSD to off load the work load is beneficial. X11 font server run into the same starvation problem and its end up basically replaced by client side free-type.

Please note early X11 protocol did not include window manager at all. Due to the cpu sizes back then cpu time starvation was a common problem so again CSD was the correct answer back then.

SSD in form of WM on X11 came in when cpu speeds appear to be doubling every year without end so if WM was too heavy you would just upgrade cpu problem solved right.

We are coming up on the end of cpu massively increasing in performance. So we are now heading back into an age where we don't have option of just tell users to upgrade hardware. We now have to start providing both CSD and SSD in applications so users can configure applications to function the best for how they want cpu time priority and interface.

[oiaohm]

Because users can't possibly be wrong?

Just like you claiming SSD was need for X11. Gnome Mutter just added a --no-x11 mode. So when that is enabled it does not need SSD for X11 any more and MPV work around of using Xwayland is also dead in the water.

The user in this case is right. You have not considered what the advantages of CSD are.