X11 as a modern display system
A lot of the old UNIX cavemen seem to have a really negative opinion of the X Window System. It seems like the reverse of the usual pattern: Those who were around to see X in its early stages seem to think it’s abject junk, but most of the younger people who inherited it as a fully formed, free Xfree86 seem to think it’s ok.
It does seem to have had a troubled start, at any rate – designed by committee, with a number of really important things just left out due to lack of expertise among the original group.
When Apple set about building themselves a new operating system, they took a UNIX-alike for the core OS, but entirely threw away X11 except as a legacy/compatibility add-on for people with existing unix software.
A project, Fresco, exists to attempt to replace X11 from the ground up.
So – I’m no X genius, just a user – what seems to be wrong with X at the moment?
Pipeline issues
Going through the X abstraction interface to draw buttons, images etc is ok, but in general it sucks for video, and most apps bypass X to draw directly into video memory in some way. This is ok, but it would be better if there was a seamless X-provided way of integrating this that degraded gracefully when the hardware access isn’t available.
Double buffering
Take a complicated app, like firefox, and move another window around in front of it quickly. Notice the ‘ghost trails’ of the app that get left behind as the program struggles to update its window as the picture is revealed? This is apparently solvable at the application level with double buffering of the window contents, but why make the application programmer care? why doesn’t the window system do this by default? This is a large part of why X11 ‘feels slow’ to the average user.
Widget set abstraction
When you see gui buttons, sliders, etc in X, they’re drawn using primitives – essentially coloured boxes, lines, ellipses and fonts. So how about that snazzy, drop-shadow, 3d-looking button? Well, that’s pretty much a bitmap that just gets dumped across into X every time we see it on screen. If it ‘animates’ when clicked, then the other frame gets dumped across too when you click it. Not cool for good performance (especially across a network). So some people want to move the widget set (buttons/menus/dials/etc) away from the app and into X itself, so the app just tells X what kind of button it wants, and X draws it locally. Pros: better performance, more consistency across apps. Cons: greater limitations – limited ability to use whatever newfangled widget set you feel like when writing an app. But I think this has to happen, basically.
Pixel agnosticism
Right now, you can see the pixels on a screen pretty easily. So it’s appropriate to have things drawn on the screen pixel-by-pixel sometimes: the font I’m seeing right now is a good example. It couldn’t be this small and still clear if it wasn’t pixel-based. But in general we’re slowly moving away from pixels. Vector art is actually getting used (Flash being the most popular example) and the bitmaps we do look at are often scaled-to-fit on our screens (such as the automatic shrinking of large images in both Internet Explorer and Firefox). 3D graphics are necessarily pixel-independent as well. With many modern video codecs (the various mpeg4s for example) the pixel concept is weakened by lossy compression that works on areas of the image rather than specific pixels, leading to images that are actually clearer when viewed at a larger size than their nominal ‘native’ size.
You see something related when you use Apple’s gui: Exposé and the genie effect both dynamically change the size of the application on the screen, yet the app is unaware and keeps updating just the same (actually there is a slight bug: mouse-click mapping isn’t updated, so if you freeze the genie effect halfway (by killing the finder during a shrink) you can still use the app, but button clicks don’t go to the new warped locations of the buttons).
I can’t think of any reason why this sort of thing can’t be essentially hacked into X11 directly; the challenge is exposing it to the developer as well as the user – we need some sensible way of dealing with pixel-independent objects in X through the API. I haven’t really thought this one through though.