The Wayland Situation: Facts About X vs. Wayland

[JS987]

Well, then we just wait until we can use SNA under Wayland. Nobody forces anyone to use OpenGL. It's just weston that uses OpenGL es primarily.

SNA is part of xf86-video-intel which depends on Xserver. Weston/Wayland/Mesa will have to support something like Xrender for SNA to be usable.

[brosis]

http://ickle.wordpress.com/2012/12/3...-acceleration/
some results which show how software rasteriser and OpenGL (glamor,GL) are slow for 2D graphics compared to Intel SNA which isn't available on Wayland

Thanks for posting this; although as noted - raster and glamor/gl are tested on non-wayland. I have, kind of, no objections that raster is slower on X. But since we talk about wayland/raster vs X/(whatever is fastest, preferably SNA), seeing that tested that would be nice.

[giselher]

http://ickle.wordpress.com/2012/12/3...-acceleration/
some results which show how software rasteriser and OpenGL (glamor,GL) are slow for 2D graphics compared to Intel SNA which isn't available on Wayland

Well, then we just wait until we can use SNA under Wayland. Nobody forces anyone to use OpenGL. It's just weston that uses OpenGL es primarily.

[JS987]

Some facts for you, before you shoot each other:
X.org is dead end.
Wayland is future.
Wayland is developed by Xorg developers.
Use some benchmarks instead of building theories - test Xorg with Xrender vs Wayland. Xorg with pixmap test is useless. Post results.
If you find performance of Wayland lacking, post suggestions.
If you think that Xorg is enough, stay with Xorg, but understand that you will have to move to Wayland with newer application versions, so better do as suggested above instead.
This is turning into religious war (as in fighting over personal beliefs).

http://ickle.wordpress.com/2012/12/30/sandybridge-acceleration/

some results which show how software rasteriser and OpenGL (glamor,GL) are slow for 2D graphics compared to Intel SNA which isn't available on Wayland

[mrugiero]

Sort of, yeah. Applications run in different "profiles" which alters how things work in various ways. It's similar to the kernel personalities in BSD and the like which allow for Linux binaries to run unaltered, but it extends down to the library level as well, similar vaguely to how glibc adds extra mangling to some symbol names so that old binaries using "fstat" or the like get a result laid for 32-bit size values but all newer binaries compiled against newer headers get 64-bit-friendly layouts. Essentially apps run in a "container" of sorts that acts more like an older edition of the OS from top to bottom.

What Linux can learn from this, I don't know. The Windows solution is horrible in a lot of ways (other than that It Works). Trying to wrap your head around WoW64 or the like is just a pain compared to the common Linux bi-arch or multi-arch setup, and XWayland is a much cleaner and easier concept to grok than "compatibility mode." The Linux way has its own annoyances, but excels in some areas. Whether or not some hybrid approach is even better we may well never know.

I'm unsure how OSX deals with such things. I think it's closer to Linux, though.

Might be added, this binary compatibility is mostly needed because of closed code. In most cases, recompiling is all that is needed, or porting results trivial. There are exceptions, of course. Specially if one didn't take precautions to make the code portable and the size of the project is big. But again, all of this requires the source code or the good will of the developer.

[elanthis]

I'm not really familiar with how these windows internals works, but perhaps windows has some sort of seamless backwards compatability that allows this, like wayland has with xwayland?

Sort of, yeah. Applications run in different "profiles" which alters how things work in various ways. It's similar to the kernel personalities in BSD and the like which allow for Linux binaries to run unaltered, but it extends down to the library level as well, similar vaguely to how glibc adds extra mangling to some symbol names so that old binaries using "fstat" or the like get a result laid for 32-bit size values but all newer binaries compiled against newer headers get 64-bit-friendly layouts. Essentially apps run in a "container" of sorts that acts more like an older edition of the OS from top to bottom.

What Linux can learn from this, I don't know. The Windows solution is horrible in a lot of ways (other than that It Works). Trying to wrap your head around WoW64 or the like is just a pain compared to the common Linux bi-arch or multi-arch setup, and XWayland is a much cleaner and easier concept to grok than "compatibility mode." The Linux way has its own annoyances, but excels in some areas. Whether or not some hybrid approach is even better we may well never know.

I'm unsure how OSX deals with such things. I think it's closer to Linux, though.

[mrugiero]

Can you please stop posting crap about windows and ms, because its completely unrelated off-topic flood?!

If one uses only toolkit and library, nothing needs to be recompiled, except toolkit for new version and new flag. Unless toolkit breaks ABI. Which will be in changelog. Of which no one from end-user perspective cares, because its easy to recompile in source based or make new package.

There is already some work happening between major library and toolkit developers and wayland developers. Those who don't do the homework, can run easily off the Xwayland.

I'm posting because there is someone asking about it.
And I stated that. I said "AT MOST". I wasn't talking exclusively about Windows in that ocassion. The reason I gave is obviously valid for the cases I enumerated later.
And it's relevant because the question is relevant, it's comparing because someone doesn't understand why one breaks compatibility and the other doesn't.
Also, I never stated anything about being hard to recompile, I'm aware that it's easy. I compile things at least twice a day, to test some toy projects of my own.

And, obviously, since there's already awareness of Xwayland, the porting we talk about is to NOT use Xwayland. To avoid an extra, unneeded, client.

[brosis]

As long as the API and the calling conventions keeps stable (if someone is better informed on ABI compatibility, please correct me, I think I might be leaving some variables out of the picture), software should be compatible. Since people don't usually write for whatever windowing infrastructure there is in Windows, but for the win32 API or for MFC, you have no knowledge of what happens under the hood. It's nothing but abstracting the implementation. Even when the windowing system changes, MS takes the work of maintaining a stable API, avoiding the erase of deprecated functions. Most of them, if not needed anymore, become wrappers around the new versions, so your app keeps working.
If you use only the toolkits without direct access to the X protocol, when the toolkit gets ported, you'll need at most to recompile for porting to Wayland. Windows does the port of the Win32 API in house, because of obvious reasons. In the open community case you can not expect that Wayland programmers port the toolkit. Even in MS is unlikely that the same people in charge of the low level windowing system takes care of the exposed API, but there are probably specific programmers in charge of that area.
And in the case of particular apps, it's a design choice. If you want your app to be toolkit agnostic, you should target Xlib or XCB, but you'll need porting to support Wayland. If you are going to use a toolkit, it's better to only use toolkit calls.

Can you please stop posting crap about windows and ms, because its completely unrelated off-topic flood?!

If one uses only toolkit and library, nothing needs to be recompiled, except toolkit for new version and new flag. Unless toolkit breaks ABI. Which will be in changelog. Of which no one from end-user perspective cares, because its easy to recompile in source based or make new package.

There is already some work happening between major library and toolkit developers and wayland developers. Those who don't do the homework, can run easily off the Xwayland.

[timothyja]

X) Everything is a window to X, there's no different window types, its just “A window.”

A) Your screensaver? Its a window that told X:
1) Put me above all other windows, at all times.
2) Make me fullscreen.
3) Give me all input.

B) A pop up window? Its a window that told X:
1) Put me RIGHT HERE.
2) Give me all input.

C) Problem? For one: they clash. Your screensaver won't activate while a pop-up window is up because they conflict.

D) Your screensaver, and screenlocker, probably didn't hook into all the necessary libraries to understand media keys... the problem there is when you're working at home listening to some music, you get up to leave, close the lid and head out. Laptop's asleep, screensaver is the 'active' window. As soon as you open the lid up, your music kicks back in, blaring out of your speakers and its just easier for you to close the lid again and deal with it later rather than scramble to put in your password, open the media player and pause it, or hit mute.

E) The developers tried to fix it. They specced out an extension, had the theory ready. But when it came time to implement it, they realized it would break the X Model too badly. This has been broken for 26yrs, and its going to STAY broken. Enjoy.

Thanks for the info I wasnt aware that X was the cause of all these issues (that affect me regularly). Tear free graphics is great but I must say these fixes have me a lot more interested in Wayland than I was previously. These issues are to me one of the last very obvious flaws with the Linux desktop, it makes me shake my head everytime I come back to my machine and close a dialog then suddenly the screensaver pops up and prompts me for my password.

As to all the hysteria over Wayland this is to be expected with any major change. I suspect once we are actually able to use it most concerns will go away. As they say seeing is believing.

[AdamW]

I'm talking about the http://en.wikipedia.org/wiki/Desktop_Window_Manager. And yet applications from before that weren't designed with DWM in mind still can work (some don't obviously), whereas in linux you have to port your application to a toolkit that supports wayland.

Well, no, you don't, it just runs through XWayland. Which is exactly the backwards compatibility layer you seem to be under the impression doesn't exist.