Xplain: Explaining X11 for the rest of us(magcius.github.io)
magcius.github.io
Xplain: Explaining X11 for the rest of us
http://magcius.github.io/xplain/article/
11 comments
This article is really helpful, I've been looking for something exactly like this.
This is pretty awesome. Love to see great write-ups of popular *nix components. Can't wait to read more!
I'd like somebody to remind me when this is finished and I can read it all. Great stuff!
You could follow progress via Github repo: https://github.com/magcius/xplain
Pardon the honesty, but this too academic, and not tasked based, for a 'rest of us' style.
Further reading: OK, this is an X developer's guide. You should call it that. It will help developers find it and stop the average Joe who wants to run a remote app on his local display from trying to use the wrong guide.
Further reading: OK, this is an X developer's guide. You should call it that. It will help developers find it and stop the average Joe who wants to run a remote app on his local display from trying to use the wrong guide.
Yeah, I guess now that I think about it I didn't think too much about that tagline.
Nicely done.
I love it that you have a server running in JS. Very nice.
Very much looking forward to the next installment.
...I've always been a bit of an X11 fanboy, so thanks for this.
...I've always been a bit of an X11 fanboy, so thanks for this.
I haven't really gone through X11 before, but the API really is terrible. How have we managed to hang onto this monstrosity for so long? I get people have a fondness for something that has held up for so long, but the huge complexity and difficulty of hardware acceleration means it's time to throw it out.
http://magcius.github.io/xplain/article/x-basics.html
Head over there and drag the kitten around to see why. Now your average Linux desktop builds a lot on X11 to get it to perform how it does now, but all this effort is a huge waste. Just compare it to something like Apple's UIKit or Android's layouts - it's well past the sell by date.
http://magcius.github.io/xplain/article/x-basics.html
Head over there and drag the kitten around to see why. Now your average Linux desktop builds a lot on X11 to get it to perform how it does now, but all this effort is a huge waste. Just compare it to something like Apple's UIKit or Android's layouts - it's well past the sell by date.
X has had a feature, called backing store, to get around that since the 80s. Individual windows can request backing store, and there's an option you can set in xorg.conf to enable backing store for all windows.
X11 actually anticipated a future of composited windows, each with their own separate buffer to draw into, well before its rivals -- due in no small part to being intended to run on much more advanced hardware than Windows or Mac OS.
X11 actually anticipated a future of composited windows, each with their own separate buffer to draw into, well before its rivals -- due in no small part to being intended to run on much more advanced hardware than Windows or Mac OS.
The issue is the added complexity of having to enable backing stores and the multiple code paths. It's not about "how much we can glue inside X11 until it sort of works sometimes".
You can throw out 95% of X11 and most developers would be much happier, bugs would go down, and everything would still work fine.
You can throw out 95% of X11 and most developers would be much happier, bugs would go down, and everything would still work fine.
Yes, that's why Wayland was invented. 95% of X11 is not necessary anymore, but it was in the 80s.
To see what?
Note that the window under it, with its white background, actually has a setTimeout when it repaints:
https://github.com/magcius/xplain/blob/gh-pages/src/article-...
Without that, even in a slow JavaScript implementation, you can barely see the white background.
As I explain in the article, this is entirely because of memory pressure limits of the 80s. This is what Windows 7 does too. And in a modern environment (compositing manager), windows do get their own backing pixel memory.
Note that the window under it, with its white background, actually has a setTimeout when it repaints:
https://github.com/magcius/xplain/blob/gh-pages/src/article-...
Without that, even in a slow JavaScript implementation, you can barely see the white background.
As I explain in the article, this is entirely because of memory pressure limits of the 80s. This is what Windows 7 does too. And in a modern environment (compositing manager), windows do get their own backing pixel memory.
> but the API really is terrible
Then use a different one, like xcb. Or even abandon it altogether and use Wayland.
> How have we managed to hang onto this monstrosity for so long?
Because it (largely) works.
And 99% of people don't ever have to come into contact with it.
> Now your average Linux desktop builds a lot on X11 to get it to perform how it does now
If you mean "builds a lot on" you mean "ignores the vast majority of outdated features of", then yes.
> but all this effort is a huge waste
Not really. A lot of the stuff replacing X11 cruft had to be implemented anyway, and the weird X11 hacks, well, they were just what was needed at the time to get work done. No use in crying over spilt milk.
> Just compare it to something like Apple's UIKit or Android's layouts
What would be the point in that? They serve very different purposes.
Then use a different one, like xcb. Or even abandon it altogether and use Wayland.
> How have we managed to hang onto this monstrosity for so long?
Because it (largely) works.
And 99% of people don't ever have to come into contact with it.
> Now your average Linux desktop builds a lot on X11 to get it to perform how it does now
If you mean "builds a lot on" you mean "ignores the vast majority of outdated features of", then yes.
> but all this effort is a huge waste
Not really. A lot of the stuff replacing X11 cruft had to be implemented anyway, and the weird X11 hacks, well, they were just what was needed at the time to get work done. No use in crying over spilt milk.
> Just compare it to something like Apple's UIKit or Android's layouts
What would be the point in that? They serve very different purposes.
>> but the API really is terrible
>
> Then use a different one, like xcb.
The problem is that it is difficult to use xcb with GLX. I just say glXChooseFBConfig. And I consider using Xlib for these API functions - as suggested on http://xcb.freedesktop.org/opengl/ as an even larger mess.
The problem is that it is difficult to use xcb with GLX. I just say glXChooseFBConfig. And I consider using Xlib for these API functions - as suggested on http://xcb.freedesktop.org/opengl/ as an even larger mess.
In his '90 Usenix presentation, Dennis Ritchie reminded the audience that
Steve Jobs stood at the same podium a few years back and announced that
X-windows was brain-dead and would soon die. "He was half-right.
Sometimes when you fill a vacuum, it still sucks."
-- Dennis Ritchie, coinventor of UNIX, from an article in UNIX Today
http://www.anvari.org/fortune/Miscellaneous_Collections/1332...
-- Dennis Ritchie, coinventor of UNIX, from an article in UNIX Today
http://www.anvari.org/fortune/Miscellaneous_Collections/1332...
The more important question of whether or not systems like C++ and X-Windows cause actual permanent brain damage in humans, will have to wait for the autopsies of human brain doners. That won't be soon, since they're still only in the animal experimentation stages. But I think it's reprehensible how they're exposing all those poor innocent bunnies to shoddy static class libraries without garbage collection, and high doses of raw Motif.
http://www.cse.unsw.edu.au/~chak/quotations.html
http://www.cse.unsw.edu.au/~chak/quotations.html
Lovely guide, too bad that it is so short: only one chapter and the introduction.
Any plans for new chapters?
Any plans for new chapters?
Yep. I'll announce them on my blog when I make a new one:
http://blog.mecheye.net/
http://blog.mecheye.net/
Great read, especially enjoyed learning about why IE6 did that thing it did[0].
I'm not sure why I enjoy reading things like this. I have no intention of getting into X development or graphics programming for that matter but it was fun read nonetheless.
[0] http://www.mrdoob.com/lab/javascript/effects/ie6/
I'm not sure why I enjoy reading things like this. I have no intention of getting into X development or graphics programming for that matter but it was fun read nonetheless.
[0] http://www.mrdoob.com/lab/javascript/effects/ie6/