Wayland & Weston Saw Fewer Commits In 2014

[phoronix]

Phoronix: Wayland & Weston Saw Fewer Commits In 2014

Going along with yesterday's X.Org Server Saw More Code In 2014 Than 2013, But Its Heydays Are Over article looking at X.Org development statistics for 2014, here's a look at the Wayland's development for last year...

http://www.phoronix.com/vr.php?view=MTg3ODg

[CrystalGamma]

Before people come and write "oh, wayland has failed, X11 4evaa!": This is called maturing.
The core Wayland protocol is stabilizing.
The bulk of the remaining work is in the applications and DEs, not in the low-level library and/or reference compositor.

[davidbepo]

Before people come and write "oh, wayland has failed, X11 4evaa!"

in fact wayland developers are xorg developers and i haven't yet seen anything bad about wayland

[d2kx]

I am still excitied for Wayland/Mir, however, I am equally happy to say that X11 has improved so much in the last few years that I am not unhappy with it.

[dungeon]

If Wayland goes to Desktop, i would probably use something else .

Still for phones it sounds fine

[Xaero_Vincent]

Wayland will be fine once proprietary drivers start supporting it or the FOSS stack pulls ahead of the the proprietary ones in both OpenGL profile compliance and performance (unlikely in the near term). Until then, X11 will be a mainstay. XWayland overhead will also need to be addressed but hopefully that is just a matter of "compositing disable" feature needed in the window managers for Wayland & XWayland full-screen applications.

[gufide]

Wayland will be fine once proprietary drivers start supporting it or the FOSS stack pulls ahead of the the proprietary ones in both OpenGL profile compliance and performance (unlikely in the near term). Until then, X11 will be a mainstay. XWayland overhead will also need to be addressed but hopefully that is just a matter of "compositing disable" feature needed in the window managers for Wayland & XWayland full-screen applications.

Wayland dows not need compositing disable. It's up to the window manager to manage it's buffer. If it decides to make one window bypass the rest of it's rendering routine, then he can do it. and it's just fine, you would get a similar result you would get with disable compositing for fullscreen window. It's just that "disable compositing" don't even make sense in a wayland world.

In X, a fully fullscreen window is supposed to put the control of the screen framebuffer to the window. so it does not behave like other windows, now your game or your video player is in control of the screen and pretty much nothing else. Now, compositing enters the game. With compositing enabled, it's almost if the window manager open a fullscreen window (to take control of the screen buffer) and displays other windows the way it want. The most common way is opengl or xrender. Now if a fullscreen window is opened, the window manager must prohibit it to fully take control of the screen buffer, otherwise compositing now don't make sense. So, to ensure everything is okay, xserver has to simulate that the fullscreen window is in control. So it changes the screen resolution, allocate a buffer for the window and then tells the window manager to display it in a "fullscreen" way. This is clearly a waste of ressource, like everything else in X. Now to allow better performance, when they are fullscreen window, the window manager can simply bypass it's normal rendering code to only display one window. That has the effect of "disabling compositing" because some useless steps are dropped thus reducing the overhead.

With wayland, there is no such steps like that. Want a fullscreen window? Great! Create a big window and let the window manager manage it. So the window manager only displays the big window and on top of everything else, and can even stop rendering other window, to get similar results as "compositing bypass", but compositing is still there and there is no performances loss like we see in the X world.

I hope I don't miss anything, if there is something wrong, please let me know!


EDIT:
Oh yeah, xwayland... that's another thing. Reducing overhead is still possible, but that's up to the xwayland library and the compositor, and pretty much nothing to do with wayland itself

[dungeon]

but compositing is still there and there is no performances loss like we see in the X world.

What performance loss you have for fullscreen apps in X world? I only know of bugs that bad/good compositors + good/bad drivers combinations can cause that.

For xwayland there will always be some overhead and for sure always more overhead then what good drivers + good compositors have under X.

I know about optimism Wayland supporters have, but those sometimes needs to be real

[CrystalGamma]

in fact wayland developers are xorg developers and i haven't yet seen anything bad about wayland

I did not mean developers. I am fully aware that Wayland is at home in the Xorg community.
I meant X11 users who seem to have something against Wayland such as dungeon here or the "but it's not network transparent!11!one!"-crowd.

@dungeon: you are aware that most games (which is where XWayland overhead would matter most) are written towards SDL2 which has a native Wayland backend? Likewise, Wayland ports for the toolkits that most non-games use are already there or currently underway. So the only kind of software that is going to need XWayland is proprietary non-game applications, which are probably not many ...

[johnc]

I meant X11 users who seem to have something against Wayland such as dungeon here or the "but it's not network transparent!11!one!"-crowd.

Hey if I can do ssh -Y hostname on Wayland then I ain't going to criticize. But if I can't, I'm not using it.

I don't care if that's called network transparency or network aware or scraping pixels, I'm just saying that some of us little people out here rely on some of these features that have been a part of X since time immemorial.