> 2) Having the X server, window manager, and compositing engine in separate processes introduces latency due to context switches on the hot path. Wayland fixes

> 2) Having the X server, window manager, and compositing engine in separate processes introduces latency due to context switches on the hot path. Wayland fixes this by making the display server, window manager, and compositor all one process. That also mean that you have a single process that if it crashes you loose your entire desktop session crashes. In the old X days I used to have my compositor crash a lot of times (good old days of Compiz with a ton of effects), but everything else was still functional, and I could simply restart it without loosing my entire desktop session. Or you changed the settings on GNOME, in the past just restart the WM, with Wayland of course you have to log out and login again. Also, things that on X were simple (for example having an application that captures the screen) are difficult in Wayland, and the only way to do so is to incorporate that functionality into the window manager itself, that becomes a monolith very quickly. Speaking about latency, to me is stupid. Like I said, in the old days of Debian 6, with a core2 and integrated graphics I used to run GNOME 2 with Compiz, I had smooth graphical effects and it did run fine, with a memory usage less than 100Mb in idle. Nowadays we have hardware that is orders of magnitude faster and we have more problems that back in the days we didn't.