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.
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.
what I effing hate is that modern applications don't just serve you 64 bit, when possible, even though many people use it. in many cases, one has to specically choose the 64 bit version. At least Apple more aggressive in offering 64 bit, even though you can still run 32 bit apps in 10.9
For the ones requesting link to prove that Wayland uses Delta-frames, it's in here somewhere, I can't be bothered finding the specific time right now (I'm 99% sure this was the vid, either that, or this one with Daniel Stone, which in any case is rather relevant to the topic).
I can't remember where, but I'm rather certain that someone mentioned binary drivers not being able to use KMS due to licensing, I don't recall anyone answering this issue. Among the bits n' bobs I've read these past days, I read somewhere that Nvidia had a workaround for this issue merged with the 3.9 kernel, so it shouldn't be that much of an issue, though I bet it'd all work better with a proper open source driver.
Now I've read quite a bit and watched vids n' stuff, and just when I think I understand everything, I read or watch something that messes with everything I think I know. So, to get the basics right:
- In the video with Daniel, it's stated that nothing in Wayland requires GL. Is EGL/GLES not considered GL-related?
- Again, the vid mentions GLES for rendering, the wayland FAQ mentions GLES/EGL untill a potential WaylandGL library vomes into existance. Considering reported Nvidias Unified EGL driver, will that have any effect on the protocol being used?
- From the info I have found so far, it seems that OpenGL communicates directly with the hardware with both X and Wayland (I'm not at all sure, everything I read tends to give a different impression from what I think I've learned). Does this mean that fullscreen OpenGL applications will still suffer from screentearing?
I apologize if any of this has been answered in either of the vids, or in this thread, but my memory is currently way past its limit.