\documentstyle[]{article}
\addtolength{\oddsidemargin}{-1in}
\addtolength{\evensidemargin}{-.5in}
\addtolength{\textwidth}{1.75in}
\addtolength{\textheight}{1.75in}
\begin{document}
\noindent
David Golombek\\
6.033 Section 6, David Wetherall\\
Paper \#3: Modularity in X\\

X is a schizophrenic beast, at once trying to provide a clean and
elegant interface to programmers, while simultaneously giving users the
highest perfomance allowed by the hardware.  The X Window API gives
programmers the ability to write graphics code that will produce
visually equivalent results across a wide range of platforms, by
simply recompiling.  This clean interface extends from the networking
to the windowing primitives.  However, to provide this clean
abstraction to end users, the internals of X itself have been made
more complicated.  This is a measured tradeoff made by the designers
of X, and has been well accepted.

Before windowing systems such as X were created, writing a portable
graphics application was a major task.  Each new platform brought a
new graphics library, and achieving identical visual results was nigh
impossible.  X provides a consistent API across all platforms it has
been ported to (almost all nowdays, from PDA to supercomputer).  This
abstraction of the hardware lets application programmers spend more
time designing their interface, on how the windows that make up their
program interact with each other and the user, rather than how they
interact with the computer itself.  Thus, the designers of X choose to
create as simple as possible for the end user (and no simpler, as
Einstein would point out).

At the same time that X runs nearly identically across platforms, it
also performs well on each of them taken individually.   Behind the
simple interface described above are several layers of code, leading
down to the machine code executing on the hardware.  The beauty of X
is how many levels are portable across all architectures, leaving just
a small hardware-specific device-driver to be implemented for each new
platform.  This modularity has paid off in the simplicity of porting X
to new hardware, as mentioned before.  Once the device drivers for
video and network cards are complete, the rest of the port is usually
straight forward.  

To provide such a low overhead in between the application and the
hardware, the internals of X are very complicated in places.  For
instance, the code mentioned as "being added in the next release" for
offscreen graphics is not simple by most code standards.  This is
considered an acceptable requirement, for this is still C code, and
thus easily portable.  If this means a loss of modularity in some
sections of the internal code, it at least preserves the abstractions
at the user level.

Unfortunately, X is not perfect.  As quick as it is, sometimes it's
not fast enough.  The recent release of Quake, a very graphics
intensive game, included the following note in it's Linux
distribution: 
\begin{quote}
A version called xf86quake, featuring the new DGA
code should be available shortly.  DGA allows direct access to the
frame buffer, page flipping, proper mouse behavior, and proper
keyboard behavior.
\end{quote}
This release clearly breaks all abstraction barriers, but it's needed
to achieve the desired performance.  Again, all a matter of tradeoffs.
Some would argue that this is asking X to serve in a manner that it
was not originally intended for, which is at least partially true, and
it's the sign of a good design that it can meet these new goals at
all. 

The X API provides an abstract interface, through several layers of
code, onto the hardware on which it is running.  Although the entire
system fills over 15 volumes of the X Toolkit Reference published by
O'Reilly (without covering all the internals), a programmer can write
a useful application with just a handful of manpages.  To achieve this
with minimal overhead is truly an impressive achievement.



\end{document}
