[rescue] Weird Silicon Graphics o2 graphics issues

[Joshua D. Boyd]

On Thu, Oct 02, 2003 at 03:18:49PM -0400, Andrew Weiss wrote:

> You misunderstand.  I said Windows also had problems with flashing 
> color maps when switching between apps at 8 bit color and below.

Your right, I misunderstood you.

> >To give each app their own 256 color colorspace is not an easy task to
> >implement on plain frame buffers.  I can think of several ways to
> >implement a frame buffer that would allow that, but each such way would
> >only be able to accomodate up to a fixed number of programs on the
> >screen at once.  Given a truecolor frame buffer though, giving each 256
> >color program it's own 256 color colorspace is an easy enough trick, if
> >done in software.
> 
> <cue partial ignorance>
> What I fail to understand is why have a colorspace (a reserved one) at 
> all.  The app wants a color out of 256 possible values... send it to 
> the screen at that spot (pixel).  I don't get the notion of firing up 
> one app that grabs all these colors and then another app cannot use 
> them while it is in the background...or may even generate errors about 
> not enough colors available.  It's not as if one app physically sucks 
> all the color into a pot and nobody else can have any...they're on the 
> same screen...or is this a memory limitation whereby you are stepping 
> into the same spot in the frame buffer's memory which needs to be 
> protected?
> </partial ignorance>

Ahh.  I think I understand where your understanding breaks down.  The
below is probably put more simply than you really need.

On the normal 8 bit VGA-like display, there are two areas of storage in
the video subsystem.  The first is the color pallet.  This storage area
has 256 entries.  Each entry contains some description of a color (for
instance, each entry is a triplet of 8 bit values[0], like 1,1,1 for white,
or 0,0,0 for black, 0,1,1 for bright yellow, etc).  Sometimes the area
is called a look up table (or LUT).

The second area of storage is the frame buffer.  There is one entry in
the frame buffer for each pixel[1], and each entry is 8 bits.  So, each
entry isn't a color, it is actually an offset into the pallet.  So, when
the video card redraws the display (which it does 60, 72, 76, whatever
times a second) it goes through the frame buffer, it takes the value
from the frame buffer and looks it up in the pallet, then it sends the
value retrieved from the pallet to the digital to analog converter.

Now.  Say I have one program that wants to use 256 different shades of
grey (for editing photos that will be printed on a grey scale printer).
Say I'm also running quake (the original 256 color version).  Quake
wants an assortment of browns, reds, yellows, etc.  Basically, both
programs want a different set of 256.  However, they have to share the
same color pallet on the video card, because there is only one pallet.  

The way the pallet is shared is usually done by the current program gets
the pallet it wants, and the ones in the background are forced to use
it.  Switch the current program, and the windowing system switchs the
pallets to use the one the other program wanted.  Because the video card
has to continuously refresh, even though the contents of the screen
might not change, it performs the lookups continuously, forcing the
background programs to be redrawn with the current pallet.

Does this make any sense?

The way you suggest is theoretically possible on some systems, just not
VGA or the systems used by most X11 servers.  I believe that the SNES
could let you modify the pallet fast enough that you could change it
between horizontal lines though, although I don't know that any game
actually ever did that, or that it was actually proven.

[0] This part deviates from VGA, but I forget the exact format used.

[1] VGA differs in the specifics, again.