9 ms·

Constraints? It was generally developed on '3-M' machines: more or less around 1MIPS of processing power (68k, VAX), 1M of memory, and 1M pixels (e.g. 1024x102

by kjs3 6y ago

Constraints? It was generally developed on '3-M' machines: more or less around 1MIPS of processing power (68k, VAX), 1M of memory, and 1M pixels (e.g. 1024x1024). While X11 is pretty grokky these days and definitely showing it's age, I'm not sure that the problems X11 solved don't exist any more. In particular, the idea of running an app on one machine and displaying it more or less transparently. It's just that with very performant desktops, this became the exception rather than the norm.

pjc50 6y ago
Solution: X11-over-websockets with display in Javascript. (Actually now wondering whether this nonsense already exists?)
- cycloptic 6y ago
  Xpra has a way to do this: https://xpra.org/trac/wiki/Clients/HTML5 https://xpra.org/trac/wiki/Clients/HTML5 There's a similar thing for Wayland too: https://github.com/udevbe/greenfield https://github.com/udevbe/greenfield And GTK has yet another way to do this built-in, that uses its own protocol: https://developer.gnome.org/gtk3/stable/gtk-broadway.html https://developer.gnome.org/gtk3/stable/gtk-broadway.html
Jasper_ 6y ago
OK, if I really want one meme about X11 to die, it's this "network transparency" one. Nobody has ever explained to me what it means, what its goals are, what constraints it has on the system or the protocol. I can't find any definition of it in any official X11 documentation, protocol or otherwise. The typical answer I see is "you can send the same bits locally that you do over the wire", but nobody ever explains why that's even desirable for a network protocol. Realities of distributed systems vs. local ones have a wide variety of tradeoffs. Transparent, distributed RPC was tried in the 90s and largely judged a failure. We know how to design much more resilient systems than that. Not to mention that ever since the introduction of the MIT-SHM protocol, which is used by most everything to transfer image data, it hasn't even been true in practice for the last 20 years. Most modern enhancements to X11 have been about taking the X server out of the loop for as much as possible. To make X11 usable over the network, even advocates of the principle usually use something like NX which is a network-designed fork of the protocol, which introduces a large number of new features aimed at network that wouldn't be required over a network, things like lossy compression, multiple independent streams so we don't have reach head-of-line blocking with roundtrips, and client-side rendering. Problems like remote desktop and streaming can be solved by other solutions than "shove the same bits over the wire and hope they're helpful on the other side".
- tgot 6y ago
  Network transparency meant that when I was doing Finite Element Analysis on the beefiest Sun workstation they sold, running a proprietary application, I could log in from home, run the application on the Sun, and see the results of the prior run. I could edit the model, regenerate the mesh if needed, and kick off another big batch run, and then drop the X11 frontend GUI. Over dial-up, from a Windows box to a Sun workstation, in the mid 90s. And it was could be secure, tunneled through SSH.
  - cycloptic 6y ago
    I'm assuming that was sending OpenGL 1.0 commands over the network, or doing some kind of equivalent. Using X11 drawing commands for that would have resulted in miserable frame rates over dial-up if you ever tried to rotate or zoom the mesh. In any case that's not really network transparency nor is it really X11, the program likely had to be built in a very specific way using display lists.
    - ddingus 6y ago
      CAD and Simulation Apps were written in those specific ways. You are right. Where that was done, performance was excellent.
      - cycloptic 6y ago
        It just seems wrong in that case to to say that X is network transparent. The real concern is that OpenGL 1.0 was capable of running over the network, and in order to use it effectively application developers had to take network operation into consideration, and the server had to support the non-standard extension required to use it correctly. In some circumstances using display lists locally could actually reduce performance, so the application may not have wanted to take that path in all cases: https://www.opengl.org/archives/resources/faq/technical/displaylist.htm https://www.opengl.org/archives/resources/faq/technical/disp... Generally if your application has any code that does this: if (client is remote) ... else if (client is local) ... Then I wouldn't say the protocol you're using is network transparent.
labcomputer 6y ago
Those 3-M machine don't have enough system memory to render every window to an off-screen pixmap and then compose all the windows onto the framebuffer. Each window (even those entirely occluded by other windows) might need up to 1MB of RAM for the pixmap (for a full-screen window on an 8-bit display). So the solution (which isn't needed anymore) is to render everything directly to the framebuffer. That means you only need num_pixels * bit_depth worth of bits on the X server, but it also means that the X server has to discard the contents of any part of part of a window that you can't see (i.e., the parts that are occluded by other windows "on top"). So when the user moves or closes a window (and reveals another window below), you don't have data for the newly-visible pixels. That's why X has a mechanism to keep track of which areas become un-occluded, and notify the client that it need those pixels again. Wayland and Mir are born in a world that generally doesn't have those constraints. We have dozens of GB of system ram, and GB of graphics memory today. Even a $25 Raspberry Pi has gigabytes of memory. So it's no problem to give 50 MB of system memory to every window (or, heck, even GPU memory) for use as an HDR+alpha 4k pixmap, and then compose those on the GPU (without using any system memory bandwidth). The application can just write to the pixmap whenever it feels like it, and let the compositor handle the rest. Even back in the mid-1990's (so, 10 years after X), low-end SGIs and Suns with 24 bit graphics often shipped with a little as 64MB of system memory. Composing off-screen pixmaps becomes a less-obvious architectural choice when each large window costs you almost 1/20th of your system memory. By the time you open your mail, browser, terminal emulator, a couple "real" applications, and the desktop background, you're spending 1/3rd of your memory on pixmaps.
- kjs3 6y ago
  Yes...this is one of the key innovations that X had that probably isn't so useful now. Efficient use of memory was critical. In the mid-1990s, low end Sun's could actually ship as a supported config with 24-bit video and as little as 20MB of memory (16M system ram + 4M vsimm) like the the SX/CG14 in the SS20. There were 24-bit cards for earlier, mc68k Suns that could run in even less, but were more for rendering and of questionable utility for interactive use. Another thing this efficiency allowed was the X Terminal. It was something akin the a serial terminal but running X, modest processor and memory, diskless (some had floppies for file transfer), usually running a couple of built-in local clients (xclock, etc), and costing far less than a full workstation. Most of them I recall being either monochrome or 8-bit color, but around this time I had an NCD X Terminal with 24-bit graphics, a MIPS processor and 16M ram + 8M vram, and network (streaming) audio for about a fraction the cost of an SGI Indy. Nice machine.

by kjs3 6y ago

pjc50 6y ago

Solution: X11-over-websockets with display in Javascript. (Actually now wondering whether this nonsense already exists?)

cycloptic 6y ago
Xpra has a way to do this: https://xpra.org/trac/wiki/Clients/HTML5 https://xpra.org/trac/wiki/Clients/HTML5 There's a similar thing for Wayland too: https://github.com/udevbe/greenfield https://github.com/udevbe/greenfield And GTK has yet another way to do this built-in, that uses its own protocol: https://developer.gnome.org/gtk3/stable/gtk-broadway.html https://developer.gnome.org/gtk3/stable/gtk-broadway.html

Jasper_ 6y ago

OK, if I really want one meme about X11 to die, it's this "network transparency" one. Nobody has ever explained to me what it means, what its goals are, what constraints it has on the system or the protocol. I can't find any definition of it in any official X11 documentation, protocol or otherwise. The typical answer I see is "you can send the same bits locally that you do over the wire", but nobody ever explains why that's even desirable for a network protocol. Realities of distributed systems vs. local ones have a wide variety of tradeoffs. Transparent, distributed RPC was tried in the 90s and largely judged a failure. We know how to design much more resilient systems than that. Not to mention that ever since the introduction of the MIT-SHM protocol, which is used by most everything to transfer image data, it hasn't even been true in practice for the last 20 years. Most modern enhancements to X11 have been about taking the X server out of the loop for as much as possible. To make X11 usable over the network, even advocates of the principle usually use something like NX which is a network-designed fork of the protocol, which introduces a large number of new features aimed at network that wouldn't be required over a network, things like lossy compression, multiple independent streams so we don't have reach head-of-line blocking with roundtrips, and client-side rendering. Problems like remote desktop and streaming can be solved by other solutions than "shove the same bits over the wire and hope they're helpful on the other side".

tgot 6y ago
Network transparency meant that when I was doing Finite Element Analysis on the beefiest Sun workstation they sold, running a proprietary application, I could log in from home, run the application on the Sun, and see the results of the prior run. I could edit the model, regenerate the mesh if needed, and kick off another big batch run, and then drop the X11 frontend GUI. Over dial-up, from a Windows box to a Sun workstation, in the mid 90s. And it was could be secure, tunneled through SSH.
- cycloptic 6y ago
  I'm assuming that was sending OpenGL 1.0 commands over the network, or doing some kind of equivalent. Using X11 drawing commands for that would have resulted in miserable frame rates over dial-up if you ever tried to rotate or zoom the mesh. In any case that's not really network transparency nor is it really X11, the program likely had to be built in a very specific way using display lists.
  - ddingus 6y ago
    CAD and Simulation Apps were written in those specific ways. You are right. Where that was done, performance was excellent.
    - cycloptic 6y ago
      It just seems wrong in that case to to say that X is network transparent. The real concern is that OpenGL 1.0 was capable of running over the network, and in order to use it effectively application developers had to take network operation into consideration, and the server had to support the non-standard extension required to use it correctly. In some circumstances using display lists locally could actually reduce performance, so the application may not have wanted to take that path in all cases: https://www.opengl.org/archives/resources/faq/technical/displaylist.htm https://www.opengl.org/archives/resources/faq/technical/disp... Generally if your application has any code that does this: if (client is remote) ... else if (client is local) ... Then I wouldn't say the protocol you're using is network transparent.

labcomputer 6y ago

Those 3-M machine don't have enough system memory to render every window to an off-screen pixmap and then compose all the windows onto the framebuffer. Each window (even those entirely occluded by other windows) might need up to 1MB of RAM for the pixmap (for a full-screen window on an 8-bit display). So the solution (which isn't needed anymore) is to render everything directly to the framebuffer. That means you only need num_pixels * bit_depth worth of bits on the X server, but it also means that the X server has to discard the contents of any part of part of a window that you can't see (i.e., the parts that are occluded by other windows "on top"). So when the user moves or closes a window (and reveals another window below), you don't have data for the newly-visible pixels. That's why X has a mechanism to keep track of which areas become un-occluded, and notify the client that it need those pixels again. Wayland and Mir are born in a world that generally doesn't have those constraints. We have dozens of GB of system ram, and GB of graphics memory today. Even a $25 Raspberry Pi has gigabytes of memory. So it's no problem to give 50 MB of system memory to every window (or, heck, even GPU memory) for use as an HDR+alpha 4k pixmap, and then compose those on the GPU (without using any system memory bandwidth). The application can just write to the pixmap whenever it feels like it, and let the compositor handle the rest. Even back in the mid-1990's (so, 10 years after X), low-end SGIs and Suns with 24 bit graphics often shipped with a little as 64MB of system memory. Composing off-screen pixmaps becomes a less-obvious architectural choice when each large window costs you almost 1/20th of your system memory. By the time you open your mail, browser, terminal emulator, a couple "real" applications, and the desktop background, you're spending 1/3rd of your memory on pixmaps.

kjs3 6y ago
Yes...this is one of the key innovations that X had that probably isn't so useful now. Efficient use of memory was critical. In the mid-1990s, low end Sun's could actually ship as a supported config with 24-bit video and as little as 20MB of memory (16M system ram + 4M vsimm) like the the SX/CG14 in the SS20. There were 24-bit cards for earlier, mc68k Suns that could run in even less, but were more for rendering and of questionable utility for interactive use. Another thing this efficiency allowed was the X Terminal. It was something akin the a serial terminal but running X, modest processor and memory, diskless (some had floppies for file transfer), usually running a couple of built-in local clients (xclock, etc), and costing far less than a full workstation. Most of them I recall being either monochrome or 8-bit color, but around this time I had an NCD X Terminal with 24-bit graphics, a MIPS processor and 16M ram + 8M vram, and network (streaming) audio for about a fraction the cost of an SGI Indy. Nice machine.