SoylentNews is people
SoylentNews
Chris Siebenmann over on his personal web page at the University of Toronto writes about X networking. He points out two main shortcomings preventing realization of the original vision of network transparancy. One is network speed and latency. The other is a too narrow scope for X's communication facilities.
X's network transparency was not designed as 'it will run xterm well'; originally it was to be something that should let you run almost everything remotely, providing a full environment. Even apart from the practical issues covered in Daniel Stone's slide presentation [warning for PDF], it's clear that it's been years since X could deliver a real first class environment over the network. You cannot operate with X over the network in the same way that you do locally. Trying to do so is painful and involves many things that either don't work at all or perform so badly that you don't want to use them.
Remote display protocols remain useful, but it's time to admit another way will have to be found. What's the latest word on Wayland or Mir?
Source : X's network transparency has wound up mostly being a failure
(Score: 5, Interesting) by TheRaven on Saturday February 10 2018, @12:21PM (6 children)
The problem with X's network transparency was that they put it at the wrong layer and so it sucked for a long time. The X protocol is entirely asynchronous, so you can batch up a bunch of commands and hide latency, but XLib exposed synchronous APIs, so you ended up with one network round trip for each line you drew. This got worse when applications moved the rendering to local buffers and used the display server to just draw them on the screen (which you needed for things like antialiased text and for sane font handling). Then things got a bit better with the trio of damage, render, and composite extensions, where you could render an image locally, transfer it to the server, have the server composite it, and only update parts that had changed.
In contrast, Sun's NeWS system, which competed with X early on, put the network at the controller layer in the MVC model. The display server had code sent to it, not just data, so your display server knew, for example, that something was a button and to animate it when it was clicked, while simultaneously sending a button-clicked event across the network to the application.
These days, the web browser is increasingly becoming a modern version of NeWS. You can send it textures, fonts, and code for drawing UIs and with WebSocket you can get low-latency asynchronous events. If I were designing a new display server, I'd think about using a NeWS-like model with WebAssembly replacing PostScript as the language for server-side interpreted code, but still expose a PostScript drawing model and OpenGL, so that it could be implemented both as a native display server and in a web browser with the canvas tag and WebGL.
sudo mod me up
(Score: 1, Insightful) by Anonymous Coward on Saturday February 10 2018, @12:39PM (3 children)
Good thing you are not, then. As if we need MORE attack surface for virii and trojans to exploit.
(Score: 2, Insightful) by TheRaven on Saturday February 10 2018, @06:12PM (2 children)
Right, because that's a much lower attack surface than X already has, where any code that runs as the current user can intercept all events and can run any arbitrary code on the GPU and can snoop on the contents of all existing windows.
You basically have two choices: run code on the display server, or accept that remote display is going to suck on any network with nontrivial latency.
sudo mod me up
(Score: 2, Informative) by Anonymous Coward on Saturday February 10 2018, @06:36PM (1 child)
https://www.x.org/wiki/Development/Documentation/Security/ [x.org]
And never assume that if you do not know about something, no one else does.
(Score: 2) by TheRaven on Sunday February 11 2018, @10:40AM
sudo mod me up
(Score: 0) by Anonymous Coward on Sunday February 11 2018, @05:30AM (1 child)
Years ago someone created a new C async binding, XCB, a more direct link to the X Protocol. XLib was partialy reimplemented with it to improve things. https://en.wikipedia.org/wiki/XCB [wikipedia.org]
But we keep getting huge toolkits that going dumber and dumber, for the great shiny and the mobile experience (yeah, in your desktop or laptop). I remember when Alan Cox discovered GNOME was really slow due to fonts, because the apps where looking for the files (instead of... I don't know, create a new font system in X11, with aliasing and proper compositing, including proper gamma correction... we got fontconfig & freetype, which assume fixed gamma and B&W colors) and doing it over and over. His home machines used NFS, so multiple file requests (for nothing in the end) slowed everything. Also I remember when one app was found recalcing own widget layout thousands of times per second, instead of a more sane 100... after all the user will not see more than the monitor refresh (anything above 200FPS would be stupid).
(Score: 2) by TheRaven on Sunday February 11 2018, @10:45AM
XCB was a huge improvement. I've written code that used it, and the model is pretty nice. You can fit it into an actor-model programming environment and defer waiting for the acks for a long time. Having XLib implemented on top of XCB simplified the XLib code a lot, but didn't really help anything using XLib, because you're still using a synchronous API on top, so the XLib APIs end up doing an async call and then blocking on the result. I don't know what the status of other toolkits moving to XCB is, but it had the potential for a lot of improvements.
The problem for X font handling was somewhat inherent in the client-server design. If you want to support fairly dumb X terminals running an X server and nothing else, then you don't want to put font handling there because installing a new font means adding the font to the terminal (which may not even have writeable storage). The XRender extension actually has a pretty sensible way of dealing with fonts. The client renders each glyph into a texture and transfers it to the server, the server can then composite the glyphs into the correct place. This is exactly the same model that Quartz uses on OS X. That said, most things using Cairo don't actually use XRENDER this way, they instead render in software on the client and send the resulting image to the server. At least if they use XDAMAGE they're not sending an entire window contents every time a cursor blinks though...
sudo mod me up