18 Oct 2000 Raphael   » (Master)

David O'Toole writes:

[...] Looking at stuff like this makes me get just a tiny bit upset about how badly the linux world is dragging its political feet with respect to improving the interface. I'm not talking about making all the OK buttons respond to the Enter key (currently my biggest pet peeve about GNOME, and it's slowly being fixed---recent GIMP etc.)

I'm talking about the imaging model. I don't want to criticize X unfairly. The X Window System was brilliant for its time and in its environment. But it simply does not support what people want to do now well enough to continue. Fast vector imaging, transparency, high-resolution monitors, antialiasing. Yes, you can implement software on top but there's no standard and it's slow.

The first defense I hear all the time is network transparency. I respond: who cares.

Well... I, for one, care very much about the network transparency of X. I am currently typing this from a Solaris machine on which I have other windows displayed remotely from a Linux machine and other Solaris machines. Not only some XTerms and Emacs that could also work over telnet/rsh/ssh, but also graphical applications like Purify, Quantify, Netscape, XMMS and some other goodies. They are all on the same LAN so speed is not really an issue. Without X's ability to display anything anywhere, writing and debugging my programs would be much harder.

So maybe I am among the 1% of people who really use the remote displays and would not be satisfied with text-based remote logins. This does not mean that nothing should be done for the other 99% who would like to get a much better performance from the applications that are running on the local display.

I don't think that it is necessary to throw X away and to start again from scratch. The DGA extension (available on OpenWindows and XFree86) proves that you can get decent performance out of X, although this requires some specific code that is rather ugly and not easy to write and maintain. Most programmers do not want to write some additional code for specific X extensions, and indeed they should not be required to do so.

But it would be possible to get a better performance while keeping the X API. Imagine that someone modifies the shared X library (libX11.so) so that if the client connects to the local server, all X calls which are normally sent to the X server over a socket would be translated into some optimized drawing operations accessing the video buffer directly. The shared X library would more or less contain some bits of the server code (actually, a stub could dlopen the correct code). If the X client connects to a remote server, then the X function calls would fall back to the standard X protocol. All clients that are dynamically linked to that modified library would automatically benefit from these improvements without requiring any changes to the code. So it can be done without throwing away the benefits of X. Actually, I believe that some people are working on that for the moment...

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!