The Wayland Situation: Facts About X vs. 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.

[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

[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.

[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.

[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.

[JS987]

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.

I think software rasteriser isn't accelerated by GPU which means even if it will be fast as SNA it will hog CPU much more.

[gamerk2]

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.

Eh, WOW64 isn't the cleanest solution on the planet, but it does get the job done nearly 100% of the time, with very little (if any) measurable performance hit. Still, when you have over a decade of closed-source, 32-bit applications that people still use, its a necessary evil. Obviously, a recompile is best, but most would rather just maintain the 32-bit .exe rather then have to build/debug two separate builds.

[Sonadow]

Eh, WOW64 isn't the cleanest solution on the planet, but it does get the job done nearly 100% of the time, with very little (if any) measurable performance hit. Still, when you have over a decade of closed-source, 32-bit applications that people still use, its a necessary evil. Obviously, a recompile is best, but most would rather just maintain the 32-bit .exe rather then have to build/debug two separate builds.

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

It's very different (or was).

Last I remembered back in OS X 10.6 they grafted 64bit userland over a 32bit PAE kernel even though the operating system installs both the 32bit and 64bit kernels.

The 64bit kernel was essentially disabled and completely hidden from view so that it would never be invoked by an end user; the only way to boot into the full 64bit environment (64bit userland and 64bit kernel) was to reboot the machine and hold down the '6' and '4' keys during the boot sequence.

Not sure how it works in the newer versions of OS X.

[bwat47]

I found here a comment by daniels mentioning the server-side vs. client-side querelle between wayland and mir. Later in the thread it is said that the difference between the two has considerable implications in terms of energy consumption.

Is there anybody that could explain why is so, and what is the rationale behing wayland choosing to be agnostic?

Thanks!

according to the comment you linked, server-side *only* had performance/power benefits on certain ARM chips, on x86 client-side is preferred, so it makes sense that wayland would be agnostic since neither one is 100% superior in every scenario.

[quasipedia]

according to the comment you linked, server-side *only* had performance/power benefits on certain ARM chips, on x86 client-side is preferred, so it makes sense that wayland would be agnostic since neither one is 100% superior in every scenario.

Hej, thanks, this answers the second question. Any idea why allocating by server (on the chips) is more energy efficient than allocating by clients? And also (new question!) why on x86 client side is preferred (still power management reasons, or...)?

Thanks!