Things to do:
-------------

 . Generic functions for ROP codes using the putPixel functions in the
   MGL so we can handle this properly. It will be slower but it will
   work.

 . Optimize internals where we see that there are bottlenecks in the code.

   1. First place to start is with the matrix manpipulation code and to
	  automatically determine if the matrices are special for special case
	  code.

   2. The second place is with the transformation of vertices to ensure
	  that this is efficient,

   3. The third place is to provide the ability to remove all internal
	  error checking for maxium performance for calls to Mesa.

   4. The fourth place is to optimize the calls to Mesa to directly call
	  the loaded API functions rather than calling the C based wrappers
	  via our MGL function pointers as this will boost performance.

   5. The fifth place is to check how the conversions between floating
	  point and integer proceed and to optimize that.

   6. The sixth place is to determine what parts of the library can be
	  optimized with high performance assembler code. The matrix math
	  and vectors transforms is one area as well as conversions between
	  floating point and integers.

 . Disable all OpenGL support unless we have linear access for speed and
   simplicity reasons.

 . Optimize solid scanline fills where the masks as all 1! Mesa should
   really optimize for this at a higher level than this, but then again
   the device drivers would probably handle this better anyway with
   optimized triangle filling code.

 . In order to support our z-buffering functions, we need to have our
   code to the zbuffer allocation stuff as we need to own the z-buffer.
   We will only support 16-bits per pixel, and we will share the z-buffer
   between the front and back buffers to conserve memory.

 . Add support for the swap hint rectangles extension in Microsoft OpenGL
   so that we can handle dirty rectangles.

 . Need to figure out how to properly handle beginDirectAccess and
   endDirectAccess within Mesa so that we can properly arbitrate between
   the accelerator and our code, but we also want to make sure that we
   optimize this to minimize the number of calls to do this. Perhaps
   we need to set up a new device driver function that is optionally
   called before a primitive or set of primitives is rendered to set up
   the direct framebuffer access to get around this problem.

   We may be able to do this with the begin/end functions, but we will
   need to enable/disable these functions depending on whether we need to
   do the direct access stuff or not for the rendering function that is
   coming up (ie: depending on the mode specific in the begin call I guess).

 . Optimize the cases for different color depths and the write_span type
   functions for direct framebuffer access for maximum speed. We will need to
   figure out the glBegin for direct access stuff, but this will give us a
   big speed improvement for basic rendering functions that we can't accelerate
   using the MGL functions.

 . Optimize the cases for glDrawPixels and glReadPixels which will be used
   to implement bitmaps and menus etc. We should be able to pass this through
   to MGL_putBitmap for simple 1:1 cases and MGL_stretchBitmap for non
   1:1 cases that need to be stretched.

 . Enable optimized dithering routines for packed pixel TrueColor devices
   using the code from the XMesa implementation. We can use these functions
   with relatively optimized plotting code direct the bitmap surface
   for reasonable speed when doing dithering in HiColor modes.

 . Add support for both 16bit and 32bit depth buffering in Mesa. I guess
   currently only one depth buffer format is supported when you compile
   Mesa which is a bit of a problem. We really want to be able to switch
   between the two formats on the fly.

   It would be nice to be able to do the same for Accumulation buffers etc,
   but it would get way out of hand handling the different combinations of
   rendering functions internally. Perhaps if we have hardware acceleration
   a 16bit z-buffer is a good choice because of the small memory requirements.

   We could cut the MGL down to support only one depth buffer size which would
   simplify a lot of the internal rendering functions.

Stuff to be updated in OpenGL/Cosmo support:
--------------------------------------------

 . Figure out how to handle the compile time and runtime extensions
   that Mesa provides that the others do not and how to provide the
   commonality between them. We need to use the same mechanism that
   Cosmo/Microsoft OpenGL use to determine the extensions and get the
   function pointers so we can do this dynamically.

New extensions in Mesa/OpenGL
-----------------------------

 . Transparent 2D glDrawPixels.
 . Dirty rectangles based on Microsoft's extension.
 . SGI's 8bpp texture mapping extensions.

Notes:
------

 . Why is the current rendering context pointer passed in to all rendering
   functions when only one context can be the currently active one? Surely
   we should simply use the global variable to avoid passing this around
   and to get faster access to the internal structures?

   Answer: to support multi-threading.

 . When we read and write pixels, what range does Mesa expect the color
   components to be in in HiColor modes (ie: 555 etc)? Should they be
   normalized to [0->255] or should they be in [0-4] etc.

   Currently it is set for [0->4] for writing and reading.

 . How are solid 2D rectangles drawn with Mesa accelerated? Are they drawn
   as two triangles or is there an optimized solid rectangle function?

 . Is there code in Mesa right now to support 16-bpp TrueColor dithering?
