
                                                16 March 2000

                 Magic Freed From 8 Bit Planes!

                      R. Timothy Edwards


This file describes the implementation of an OpenGL interface for
magic.

The purpose of these changes is:

   Avoid the limit of 8 bit planes imposed by the pseudocolor colormap
   without compromising the quality of the display by using stipples
   in place of solid color fills.

Details:

   Magic is losing ground to 1) new VLSI fabrication
   processes, and 2) new video cards.  The first is not
   necessarily a problem:  magic is well thought out and
   surprisingly versatile.  However, the second was giving
   me fits a while back when I found that magic only runs
   in 8-bit colormap (pseudocolor) mode, while many of my
   other X11 applications wouldn't run at all and were only
   happy in 24-bit (TrueColor) mode.  This is particularly
   true of Linux and the new breed of window managers and
   GUIs such as KDE which normally expect the desktop
   visual to be 24-bit TrueColor.  I was forced to
   close my X session and restart in 8-bit mode to get
   magic to work.  Then, I would often get the problem
   that by installing its own 8-bit colormap, magic would
   cause the colors of the xterm which it uses for text
   I/O to become unreadable.  Later, I bought the Xi
   Graphics X11 server which supports 8-bit overlays on
   top of a 24-bit color, and that works well, but I
   regard it as a temporary solution.

   Magic makes good use of its color bit planes to represent
   layers in the VLSI layout.  The result is a display that
   looks better than any of the multi-thousand-dollar
   professional layout tools (Cadence or Mentor Graphics,
   which use stipple patterns on a harsh black background,
   or Tanner's L-Edit, which is still backwardly-compatible
   to the original 4-plane color and uses a harsh white
   background).  The problem with magic is that the 8-bit
   colormap mode is increasingly considered "archaic" and
   is less well supported as applications move toward 24-bit
   color.  Also, fabrication processes have moved toward
   multiple metal and poly layers, which exceeds the
   capacity of 8 bit planes to represent separate fabrication
   layers.

   I have a solution:  write a new graphics interface to
   magic for OpenGL.  Why?  OpenGL is supported by many
   high-performance video cards.  It can do color blending
   in hardware, which gives similar results to what magic
   does with careful allocation of colors in the colormap.
   And:  it's not limited to eight bit planes.  And:  it
   works in 24-bit color.  And:  say goodbye to stipple
   patterns.  All layers can be represented by solid colors,
   and non-edit cell layers can have that "washed out" look
   without compromising graphics resolution.  The results
   are stunning.  Ideally, the interface would be based on
   "glut", the generic graphics API for OpenGL, which would
   avoid making explicit calls to X11 functions and make
   magic easier to port to non-UNIX operating systems
   (namely, Windows).  Unfortunately, this approach got
   bogged down in a problem with threads and Xlib.  The
   final answer on that is:  Don't ever multithread an
   OpenGL program unless you're sure you have 100% control
   over the relative timing of the execution of all X11 and
   OpenGL calls.  Instead of glut, this implementation is
   based on glX, the more specific API detailing the
   use of OpenGL within an X11 environment.  This method
   keeps the original X11Handler as the event manager for
   magic, and uses X11 cursors and a few other routines.
   Everything else is rendered using OpenGL commands.

Usage notes:

   Especially for Intel x86 and compatible platforms:
   Don't attempt to using magic/OpenGL with the Mesa OpenGL
   library unless you have video hardware support (as far as
   I know, this is only true for the Voodoo cards).
   More specifically, the hardware has to support color
   blends (GL_BLEND function);  otherwise you will be waiting
   all day long for magic to draw your chip layout.  There
   is one (commercial) driver available as of this writing
   (Xi graphics 3D Accelerated X server, see www.xig.com,
   works with several dozen video cards), and promises for
   the near future from SuSe, RedHat, MetroX, and Precision
   Insight.  I am assuming that this is the wave of the
   future;  otherwise, I wouldn't bother with the
   implementation.  OpenGL rendering under the Xi Graphics
   server is a bit slower than with the X11 interface, but
   benchmarks are a complex combination of driver, card,
   revision numbers of each, processor type and speed, and
   magic implementation.

   If magic is compiled only for OpenGL, this will come up
   as the default.  Otherwise, if it is compiled along with
   X11, X11 will be the default and it will require typing

   > magic -d OGL

   on the command line to get the OpenGL graphics.

Implementation notes:

   OpenGL is normally considered a 3D rendering engine;
   here, I make use of 3D hardware acceleration, but all
   transformation matrices are aligned perpendicular to
   the depth (z) axis.  There is no colormap;  although
   OpenGL can work in color index mode, there is no
   point in doing so because the X11 version would be
   faster.  For reasons of simplicity, the OpenGL
   version takes its color input from mos.7bit.std.cmap1,
   although instead of plugging them into a colormap, it
   sets the color according to their RGB values.  The
   mos.7bit.std.cmap1 has been extended to include a set
   of solid colors which implement the "washed out" look
   of magic's non-edit cells without reverting to the
   checkerboard stipple pattern.  Existence of the gray
   background made the color blending tricky, because
   anything blended with gray becomes grayer.  However,
   OpenGL allows color specs to run outside of the
   normal color boundaries;  it only cares whether the
   color values map to real video values after all
   transformations (like blending) have been performed
   on the color values.  So we compute "super-colors"
   which can be whiter than white and blacker than
   black, but which arithmetically resolve to the
   usual magic colors when blended with the background
   gray.  This achieves the desired effect.  The only
   real difference between the OpenGL and X11 displays
   is the blend colors, which are always "computationally
   perfect" blends of multiple solids in OpenGL but have
   been tweaked for aesthetic effect in the X11
   colormap version.  This effect has been reproduced
   in the OpenGL version by tweaking the color, style,
   and tech files.  In addition, new styles have been
   added for poly2 and capacitors.
      OpenGL has several emergent features unavailable
   in the X11 version:  one is an unlimited number of
   solid colors (and their mixtures);  this made all
   the difference on my layouts in 3-metal layer
   technologies, where the 3rd metal layer covers large
   areas and makes parts of the circuit uninterpretable
   when viewed through the nasty cross-hatched magenta
   stipple.  Under OpenGL, the magenta color is perhaps
   still a bit severe, but the whole circuit is easily
   viewed underneath.  The second emergent benefit is
   that layers of the same material which overlap in
   separate cells are drawn darker at the overlap (due
   to the blending function), so it is much easier to
   see where one cell ends and another begins.

Bugs:

   Bugs of the source and of the glX driver are difficult
   to separate.  My Xi Graphics 3D Accelerated-X server
   previously had problems drawing over X11 windows
   overlapping the magic window;  this behavior has
   disappeared in the current distribution of the X
   server (May 2000).  A good test of server bugs is
   to run magic/OpenGL on an SGI machine, which has a
   stable implementation of OpenGL.

Files changed are:

1. scripts/configure.in		(altered)

2. graphics/Makefile		(altered)

3. graphics/grOGL*.c		(new)
   graphics/grTOGL*.c		(new)

4. scmos/mos.7bit.std.cmap	(altered)
   scmos/mos.OpenGL.dstyle	(new)
   scmos/mos.7bit.dstyle	(altered)
   scmos/*.tech			(altered)

