[twenty-years: 3/4] graphics.tex: Start filling in



commit 2f7c0025e1c8d44d4183b6dbee414d4b2a16767c
Author: Federico Mena Quintero <federico gnome org>
Date:   Fri Apr 14 07:33:16 2017 -0500

    graphics.tex: Start filling in

 book/graphics.tex   |   92 ++++++++++++++++++++++++++++++++++++++++++++++++--
 book/main.tex       |    1 +
 book/references.bib |    7 ++++
 3 files changed, 96 insertions(+), 4 deletions(-)
---
diff --git a/book/graphics.tex b/book/graphics.tex
index 4bdda84..d7a5f42 100644
--- a/book/graphics.tex
+++ b/book/graphics.tex
@@ -1,15 +1,99 @@
 \chapter{The Quest for Beautiful Graphics}
 
-Xlib
+Starting \GNOME\ was possible because the \gls{GTK} toolkit had already
+been extracted from the \gls{GIMP} --- this made it possible to write
+stand-alone applications without having the \gls{GIMP} installed.
+
+And before that?  \gls{GTK} was started precisely because there was no
+good, free toolkit for graphical user interfaces before that.  There
+was the ``standard'' X Toolkit --- really, a toolkit construction kit --- and
+the X Athena Widgets (Xaw), which were hard to program and looked
+ugly.  There was Motif, a proprietary toolkit which was very much in
+vogue for proprietary applications for Unix.\footnote{For a detailed
+  explanation of how the X window system works, and for the history of
+  the ``new'' additions to make it friendly to high-quality graphics,
+  you may want to read \cite{magcius-xplain}.}
+
+The first versions of the \gls{GIMP} were written with Motif.  This
+made it impossible for people to write plug-ins, or even to contribute
+to the core, without having Motif licenses.  The \gls{GIMP}'s authors
+wrote the plugin API so that it would let plugins create very simple
+user interfaces by requesting a few text-entry or numerical fields.
+In turn, the core GIMP process, which was linked to Motif, would
+generate the appropriate dialogs and widgets based on the plugins'
+requests.
+
+For the \gls{GIMP} 0.60, Peter Mattis started writing an entirely new
+toolkit called GTK: the GIMP Toolkit.  The API looked very different
+from what we have now.  But from the start --- being the core of a
+graphics-heavy program --- it had good support for displaying RGB
+bitmaps, something that was hard to do in toolkits derived from Xt.
+At that time, graphics cards with 24 bits per pixel were rare; most
+PCs and workstations had 8-bit indexed color graphics.  GTK had all
+the necessary machinery to quantize, dither, and display 24-bit RGB
+buffers relatively easily.
+
+Still, we didn't have an easy, generic way to load image files.  The
+GIMP knew how to load formats like GIF, PNG, and JPEG with its
+plugins, but even its internal icons for the user interface were
+defined in simple, ad-hoc formats that were easy to parse from a C
+program.
+
+\section{Imlib}
+
+Imlib was the library that the Enlightenment window manager used to
+load raster image files.  It had been written exactly to do that, and
+the API reflected it.\footnote{The Imlib source code is still
+  available at \url{https://git.gnome.org/browse/archive/imlib/}
+
+Imlib had an API that was good for Enlightenment, but not very
+convenient for a general-purpose image loader.  You could specify a
+filename to load, and you would get back a handle to an Imlib object.
+From that handle you could render the image into an X pixmap, which is
+a server-side resource.
+
+Imlib had some peculiarities due to being used for a window manager's
+graphics.  It included a cache for loading images from files, so that
+the window manager could ask it to repeatedly load the same image ---
+say, a beveled button that was reused several times in a window's
+title bar --- and get the same X pixmap back.  It was not possible to
+separate the caching from loading or rendering.  And when an image was
+finally freed, its data could remain in the cache indefinitely.
+
+Also, Imlib really wanted the user to render the whole image into an X
+pixmap.  It was not possible to render only a sub-region.  This put a
+lot of pressure on the X server whenever a large picture was
+loaded.\footnote{Although at that time digital cameras were just
+  started to get popular, they only generated 640x480 pixel images.
+  To get high-quality raster images, one used a scanner.  Still,
+  images larger than about the size of a computer monitor's resolution
+  were considered ``very big''.}
+
+Also, Imlib only supported 1-bit transparency, that is, a simple mask
+for ``shaped'' images.  It was pretty hard to support full
+transparency, or an alpha channel, with the graphics hardware and X
+APIs available back then.
+
+Imlib was very constrained to the hardware limitations at the time.
+For example, it was very concerned with having the correct X colormap
+(an RGB palette with a limited number of colors) and X visual (a
+description of a graphics card's capabilities) corresponding to the
+window on which you were going to render your image.  This is very
+different from today's APIs, which all assume ARGB buffers and 24-bit
+color displays.
+
+\section{Libart}
+
+
+
+\section{GdkPixbuf}
+
 
-Imlib
 
 Libart
 
 librsvg
 
-Gdk-pixbuf
-
 Itsy / handhelds, Xfixes, XRANDR, Xrender - the modernization of X
 
 Cairo
diff --git a/book/main.tex b/book/main.tex
index 6d4ee03..eaaea2a 100644
--- a/book/main.tex
+++ b/book/main.tex
@@ -21,6 +21,7 @@
 
 \def\GNOME{{\sc gnome}}
 \def\KDE{{\sc kde}}
+\def\GIMP{{\sc gimp}}
 
 \makeindex
 \makeglossaries
diff --git a/book/references.bib b/book/references.bib
index 0015c02..1dedde3 100644
--- a/book/references.bib
+++ b/book/references.bib
@@ -41,3 +41,10 @@
        year    = {2002},
        url     = {http://ometer.com/free-software-ui.html}
 }
+
+@online {magcius-xplain,
+        author = {Jasper St. Pierre et al}
+        title  = {XPLAIN: Explaining X11 for the Rest of Us}
+        year   = {2017}
+        url    = {https://magcius.github.io/xplain/article/index.html}
+}


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]