GNOME Shell & Mutter Can Now Be Extensively Profiled For Missed Frames, Other Metrics

[Vistaus]

The stats you show actually show the opposite of what you're saying with most users using either KDE or Gnome, their combined share bigger than all the others put together and their individual shares being two times larger or more than each of the other desktops when compared individually.

Yeah, plus that website is gaming-oriented, so it doesn't even count when talking about total desktop market share.

[finalzone]

Colors are still missing. Instead, the gnome 3 desktop distracts users with bugs and bad design.

Which users? What distraction considering the minimization of desktop on Gnome Shell? Gnome Shell turned out very productive for video editors, photo editors, illustrators to name a few without too much bling bling.

[Tuxee]

Puhleeze Michael,

can't we get rid of the debianxfce troll? It would improve the forum quality immensely.

[Pajn]

Stuff like this raises the question. How many wayland Desktop compositors do we need?

Mutter is by far the most tested, mature and performant compositor. Ideally we only need one.

Van Vugt is still fixing issues in Mutter that was fixed a long time ago in Mir, or never even existed in the first place because the design was just better.

And by tested, Mir also outsines Mutter in actually measurable test coverage.

It's sad that the community killed Mir because now we are stuck with a compositor that was a badly designed X window manager with a very hastily and basically undesigned compositor bolted on.

[oiaohm]

A great action from gnome3 developers to prevent the success of the Linux desktop. No themes.

https://linuxreviews.org/GNOME_Developers_have_Made_Their_Moves_against_Themes

Bravo IBM-Microsoft.

https://stopthemingmy.app/

Not a single IBM/Redhat developer on that list. This theme issue can make XFCE not usable as well. One of the big problems is the GTK stylesheet system.

Problem 1 theme style sheet has to be complete alone.
This means some new feature that is wanted theme can be missing from the style sheet of a third party theme so cause applications to go bad. This need to be overlay system or filtered. System base theme gets overlay with active theme is one way to make sure you don't have missing enteries. Filtered where the theme just fails out and drops back to defaults because it does not contain the entries the application needs would be another option. Hey this applications not themed ok better update/change theme..

Next is lack of clear define between application private widget modification and global theming in style sheet.

GTK stylesheet theming is not a IBM or Redhat design either. It was web developers use CSS so we as web developers using gnome who at the time made up the majority of gnome users/developers would like theming done the way we know. Yep CSS is not even a simple change theme on websites. The base idea of GTK theming is busted. Qt also has the same problem.

Theming per application works with the current stylesheet system. Theming desktop wide is badly broken.

[DeeZiD]

Which users? What distraction considering the minimization of desktop on Gnome Shell? Gnome Shell turned out very productive for video editors, photo editors, illustrators to name a few without too much bling bling.

Even for Drag and Drop operations. It just makes sense and I honestly miss it every time I have to use a Windows desktop...

[oiaohm]

Stuff like this raises the question. How many wayland Desktop compositors do we need?

Mutter is by far the most tested, mature and performant compositor. Ideally we only need one.

Really I would not say 1. KDE compositor and Weston are fairly well tested as well.

This is really like how many Windows managers should X11 have. KDE vs Gnome has been on going in the X11 compositors for a very long time. Now that we have Wayland compositors this should basically keep on going forwards.

Sway is built for tiling windows management this is different to KDE or Gnomes offering. We do need some competition 144Hz its hard to judge how good something is without something to compare to.

Of course I want to see all of them end up with Sysprof or equal tools. One of the biggest problems on the desktop has been a lack of means to totally benchmark and locate exactly where the problems are. Like with Mutter most installs less than 10 percent of the processing time is spent in javascript and a lot of problems have been put down to javascript problems but now they have proper bench/profiling its like hang on that not javascript problem that over here causing the stall. Of course after they fix all those other faults I do expect the largest cause of slowdown of mutter to come back to javascript. We do need a decent desktop compositor that does not depend on scripted plugins as a reference here for how bad script in compositors are.

I do wonder if in time this will allow better work on the Linux kernel scheduler once you can in fact document how the scheduler is screwing over desktop loads.

[oiaohm]

oiaohm many thanks for you answer. It really didn’t answer the big question. Where do we get tools and resources to develop redundant compositors? Mutter is doing well.

Its that you are not looking past skin deep.

https://en.wikipedia.org/wiki/List_of_display_servers

Enlightenment	BSD license	C	libwayland-server (MIT License)	EFL	Yes	Yes	POSIX
Gala Window Manager	GPL	Vala	GTK+	Yes	Yes	POSIX
KWin	GPL	C++	Qt 5	Yes	Yes	POSIX
orbment	GPL 3+	C	wlc, libinput2	Yes	No	No
Lipstick	LGPL 2.1	C++	Qt 5	Yes	No	No
Mazecompositor	MIT License	C++	Qt 5	Yes	No	No
Mutter	GPL	C	GTK+, libinput2	Yes	Yes	POSIX
Weston	MIT License	C	libinput	Yes	Yes	POSIX
Sway	MIT License[1]	C	wlroots[2], libinput2	Yes	Yes	POSIX
Way Cooler	MIT License [3]	Rust	wlc, libinput2	Yes	Yes	POSIX

Lets take a closer look as this table does. Notice for client to wayland compositor every solution is using libwayland-server. So there i no duplicate work there.
wlc and wlroots in that chart are in fact the same thing.

EFL, GTK, Qt5 have something in common they are used embedded so they have maintained a code for running without X11 server or wayland compositor any how. So output by EFL, GTK and Qt is not extra development cost.

All input is done by libinput even that the chart does not show that and if you have not notice is very quickly becoming the only x.org X11 server input system.

Weston is about the only one going direct by itself. Enlightenment is not directly by themselves because EFL is used by embedded developers. Wlroots/Wlc is already shared by 3 projects.

Lets consider Mutter and Kwin as a X11 compositor majority of it code is in fact using GTK/Qt as a wrapper to X11.. The wayland versions of both of them are very limited extra work.

You could say making x.org X11 server drivers are redundant work duplicating what has to be done in the toolkits like EFL, GTK, Qt for embedded developers running applications without a display server.

Once you work out how much is being done in toolkit suitable for usage without a display server and how much is done in libwayland-server.the result is in fact less code per compositor than making a X11 compositor using the X11 composite extension.

Someways we need to speed up migration to Wayland to in fact free up developer hours.

redundant compositors

this misses that we have been having redundant driver implementations. Driver implementations equals at times needing NDA and being in the right country.

Before wayland the driver mess looks like this.
1) Embedded drivers for direct output per toolkit with some UMS and some KMS and some framebuffer.
2) X11 drivers. some UMS and some KMS and some framebuffer.
Yep these two stacks don't in fact overlap with each other. So some output devices you could not use X11 because you did not have the driver or you could not use embedded for direct output because it was not support.

After wayland we have had the hard push to KMS only drivers. So in time this comes Embedded drivers for direct output and desktop per toolkit. So completely in time losing the X11 drivers. Please remember x.org project has been massively under resourced to maintain the X11 drivers. Qt for example due to commercial usage can afford full time paid staff to take care of it. x.org cannot afford this.

Basically like it or not there is not the resources to maintain x.org X11 server in it current form. Maintaining xwayland long term is going to be pushing things up hill. If lucky modesetting driver remains as well. The other drivers making my x.org X11 server you can expect to bite the dust and they really don't have a choice in the matter. The UMS stuff already has bit the dust.

Yes long term there is no more work maintaining a Wayland compositor vs a X11 compositor in fact it less work. Sooner we can lose x.org X11 server from direct output the better because this will free up resources. Hopefully some of those those resources go into being able to benchmark/profile stuff well for performance issues.