3 ms·

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 wi

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.
- icedchai 6y ago
  I remember working in a lab full of X terminals. They were NCDs, now that I recall. They all ran off of DEC Alpha or DECstation servers. That environment was pretty snappy.
- cbm-vic-20 6y ago
  Some of our university computer labs in the mid-90s were set up this way: a room full of X Terminals that you could use to connect to the big Alpha machines in the datacenter, or the Sun machines if you needed the software that ran on them, etc. When Linux with X came around, it was awesome to be able to dial into the modem bank and get connected to these machines from home.
  - kjs3 6y ago
    I deployed a couple of thousand NCD xterms at a Very Large airline backed by a cluster of very large Sun machines running a customer service application. Would have been late 90s. Very successful once the network performance issues were wrung out. Good times.

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.

icedchai 6y ago
I remember working in a lab full of X terminals. They were NCDs, now that I recall. They all ran off of DEC Alpha or DECstation servers. That environment was pretty snappy.
cbm-vic-20 6y ago
Some of our university computer labs in the mid-90s were set up this way: a room full of X Terminals that you could use to connect to the big Alpha machines in the datacenter, or the Sun machines if you needed the software that ran on them, etc. When Linux with X came around, it was awesome to be able to dial into the modem bank and get connected to these machines from home.
- kjs3 6y ago
  I deployed a couple of thousand NCD xterms at a Very Large airline backed by a cluster of very large Sun machines running a customer service application. Would have been late 90s. Very successful once the network performance issues were wrung out. Good times.