[…] 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…