There were a few implementations of X for different unixes. Mostly closed source. It was very buggy, and patches were posted online, under the form a LD_PRELOAD-ed libraries. iirc, I had to preload a few libraries to work around the HPUX X implementation to be capable of running Mozilla Suite.
Fun times :)
It wasn't simply renamed Xorg, that's yet another fork after XFree86 development became stagnant and the license changed to something GPL-incompatible.
https://en.wikipedia.org/wiki/XFree86#2002:_Growing_dissent_...
I have been using it (and its derivatives) for more than 20 years and only got the pun now!
It is mentioned in the Wikipedia page[0], unfortunately no citation to validate the story. Though I found it talked about in Linux Magazine's "The History of XFree86" article[1] (under "The Rebirth" section)
[0] https://en.wikipedia.org/wiki/XFree86#Early_history_and_nami...
But that ship hasn't totally sailed right? It's not as if Wayland was the amazing tech everybody hoped for and jumped to. Wayland is old by now, it's only half a success and many of us are still using Xorg.
I'm not saying that in two decades Xorg may not be gone for good but at the moment Wayland and Xorg still coexist.
He "solved" the issue by lowering the video card refresh rate (60hz -> 30hz) -- iirc.
Can't find that post anymore, but I always wondered if that approach would have allowed me to dive more displays with my integrated intel gpu. I was unable to go further than three 1920x1200 external displays (I had to sacrifice the fourth display, the laptop's built-in display)
I had not enough VRAM in a computer to do 16 bit 1024x768 but the difference was tiny. I think it needed a few tiny buffers for the mouse cursor and dragdropped icon, which was advanced 2d hardware acceleration at the time (Onion, belt, ...),and whatever memory was left just did not make it by a hair.
So I wrote a custom modeline to create an absolutely nonstandard videomode. I think the only requirement was that vert and horiz resolution were divisible by 4, so I did 1000 by 752 or something like that.
You had to make sure the dot clock was acceptable, or you could physically damage the CRT. Scary. So I did the calculations and tripple checked everything, then started a custom config with my thumb on the power button. It worked.
> MGR featured overlapped [...] windows and [...].
Took a while to see the strength of tiling window managers.
https://en.wikipedia.org/wiki/NeWS
which had the interesting idea of using PostScript to drive the display.
Tektronix had one with a "storage" scope that would retain (for a while, fading) a picture drawn once with a vector-steered electron beam. There was a graphics board to plug into a DEC VT100. HP had such a terminal. I think the VT100 card took the same codes as the Tek, but the picture would stay until erased.
Programs to draw graphics would need a driver layer to work on different terminals. If you were clever, the same code could drive an X-Y pen plotter, typically from HP. Good times!
You could buy a knife-pen and put rubylith in the plotter, and cut out circuit board optical masks, usually at 4x or more magnification. Rubylith was two layers of plastic, dark red and soft on clear and hard. The knife would cut just through the red layer. Peel off the stretchy red stuff where you didn't want traces, and send the rest to the PC board shop.
If you keep the screen buffer as (part of) the backing store for the pixels of windows, you also have to make drawing code clip to any overlapping windows. If you don’t, memory usage goes up again.
And memory could be tight. As an extreme example, the screen memory on an original Mac was about the same size as the amount of memory available to the running application.
It did overlapping windows, and the program was expected to re-draw the part exposed if you moved one.
The 512k version, or "Fat Mac" came out soon after, and was actually useful.