2. X11 does lack critical features that lots of users need: GUI isolation (a very basic security measure that's otherwise been standard practice for decades), mixed DPIs, and perf on low-end ARM devices (compare Sway with dwm/openbox/i3 on a rbpi or pinebook and the difference is kinda shocking).
Factor all this into account and I'd be interested in seeing an X setup without screen tearing that performs at least as well as Sway on a Pinebook or a rbpi.
You're right, compositors weren't a thing, but we're also talking CPUs several orders of magnitude slower, and where the blitter capabilities of what passed for GPUs had a throughput magnitudes slower than what my cellphone has today.
The difference will widen as Vulkan support in Wayland compositors seems to be outpacing the X equivalents; modern GPU development is starting shift away from OpenGL
I have never seen any screen tearing in my life by the way. Despite I have always been generally using decade-old PCs with lowest-end (mostly built-in) GPUs and Raspberry Pi is the only way I watch TV. The only annoyance I have with Raspberry Pi is YouTube the website (not the actual video, it plays Ok) being rather slow.
The delays and latencies for me have been noticeably lower when using Sway on ARM, which is quite surprising because I was expecting the opposite. I hadn't even tuned it for low input latency yet.
Recreational Bugs talk [1989] by "Sgt." David Rosenthal (author of the ICCCM, the Andrew Window Manager, and NeWS, and an old friend), who explained the 80's era X-Windows hardware model and war on drugs quite well here:
https://blog.dshr.org/2018/05/recreational-bugs.html
>"You will get a better Gorilla effect if you use as big a piece of paper as possible." -Kunihiko Kasahara, Creative Origami.
https://donhopkins.medium.com/the-x-windows-disaster-128d398...
>The color situation is a total flying circus. The X approach to device independence is to treat everything like a MicroVAX framebuffer on acid. A truly portable X application is required to act like the persistent customer in Monty Python’s “Cheese Shop” sketch, or a grail seeker in “Monty Python and the Holy Grail.” Even the simplest applications must answer many difficult questions:
WHAT IS YOUR DISPLAY?
display = XOpenDisplay("unix:0");
root = RootWindow(display, DefaultScreen(display));
win = XCreateSimpleWindow(display, root, 0, 0, 256, 256, 1,
BlackPixel(
display,
DefaultScreen(display)),
WhitePixel(
display,
DefaultScreen(display)));
(the next client tries to connect to the server)
WHAT IS YOUR DISPLAY?
display = XOpenDisplay("unix:0");
cmap = DefaultColormap(display, DefaultScreen(display));
favorite_color = 0; /* Black. */
/* Whoops! No, I mean: */
favorite_color = BlackPixel(display, DefaultScreen(display));
/* AAAYYYYEEEEE!! */
WHAT IS YOUR DISPLAY?
display = XOpenDisplay("unix:0");
struct XVisualInfo vinfo;
if (XMatchVisualInfo(display, DefaultScreen(display),
8, PseudoColor, &vinfo) != 0)
visual = vinfo.visual;
/* Is that a SubstructureRedirectMask or a ResizeRedirectMask? */
(server dumps core & falls into the chasm)
I'm aware it ran on mid 80's hardware, but I didn't personally have experience with X that far back, so I stuck to what I knew for a fact it handled fine :)
> WHAT IS YOUR ROOT?
A lot of these are macros in Xlib that obscures that they're "just" looking up things in the display info returned on opening the display, though.
The X protocol is messy in places, but Xlib is far worse than necessary. I'm currently toying with a pure Ruby X protocol implementation (client side only; "why?!?" I hear you ask - I guess I must be a masochist; the real reason is that I'm writing a terminal in Ruby and the C extension annoyed me; I only need a small subset of the X protocol in any case; the reason I'm writing a terminal is that I'd like to experiment with terminal extensions to integrate with my editor - also in Ruby - turtles all the way down... I guess this just conclusively proves that I'm a masochist), and thus was forced to learn that the initial display info returns the list of screens and the root, and the black pixel value and the white pixel value.
So there's no good reason for the client to keep being this complex other than inertia - few people write applications directly to xlib and so there's little incentive to make it better.
There are lots of things in X that would be nice to ditch, though. I just wish there'd been a more gradual approach.
In fact, I've seen some want to keep maintaining Xorg - if someone ends up doing so, I'd strongly recommend they'd take the Wayland approach of a rootless X server for legacy clients, and then doing a review of clients and aggressively deprecating features which are mostly unused by modern clients.
EDIT: In fact, an X proxy that re-implements deprecated features would be very simple - it "just" needs to understand enough of the protocol to pass on packets it doesn't want to handle, and to rewrite sequence numbers if needed. Then it could do nothing if it connects to a "legacy" X server, but intercept requests when connecting to an upgraded X server. There are already several X proxies of varying capability that could serve as a starting point - e.g. Xephyr and Xnest.
1.: https://github.com/emersion/hello-wayland/blob/master/main.c
That's also exactly what most modern GUI toolkits do when they run on X11.
Doesn't the server tell the client what to render, and the rendering happens on the client? Why would that result then be shipped over the network?