[rescue] Weird Silicon Graphics o2 graphics issues

[Phil Stracchino]

On Thu, Oct 02, 2003 at 03:18:49PM -0400, Andrew Weiss wrote:
> <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>

OK, here's the basic problem.

Suppose you have a color table with 256 entries.  And you have 15
different programs running, all of which are using a collective palette
of colors that can be filled using 30 of those 256 entries.  So far, so
good.

Now, you open another application, which uses those same set of standard
colors, PLUS it wants to render an image which has 8 bits of color
depth and uses 242 distinct color values.  Let's say you get lucky, and
19 of those color values are already allocated in the 30 entries
everyone's using.  That leaves 223 color values to allocate, and you
have 226 entries left in your table, so you allocate 223 more entries
and everything's happy -- SO FAR.  But now you only have 3 unallocated
color-table entries.

Now you open *another* application, which *ALSO* wants to render an
8-bpp image, this one having 179 distinct color values.  135 of the
color values it wants to use are already present, allocated in either
the 30-color "shared palette" or the 223 colors the *other* image viewer
allocated.  That leaves 44 color values to allocate, and 3 color table
entries to do it with.

This is the point at which you say "Oops."  The second image viewer can
exactly render 138 of its 179 desired color values (135 that are already
allocated, 3 more using the 3 open entries), but for its remaining 41
color values, it has to accept the closest matches from the colors that
are already allocated.  If the two images have widely differing color
gamuts, the situation may be much worse -- the second image viewer may
be able to get exact matches for only, say, 22 of its desired 179 color
values, and accept "closest approximations" for the remaining 157, and
if the images are very different, then those "closest approximations"
may not be very close at all.


Do you understand the problem now?



-- 
 .*********  Fight Back!  It may not be just YOUR life at risk.  *********.
 : phil stracchino : unix ronin : renaissance man : mystic zen biker geek :
 :  alaric at caerllewys.net : alaric-ruthven at earthlink.net : phil at latt.net  :
 :   2000 CBR929RR, 1991 VFR750F3 (foully murdered), 1986 VF500F (sold)   :
 :    Linux Now!   ...Because friends don't let friends use Microsoft.    :