Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!decwin.DEC.COM!fisher
From: fisher@decwin.DEC.COM (VMS DECwindows Engineering, 381-1466)
Newsgroups: comp.windows.x
Subject: Re: visual depth vs. colormap_size
Message-ID: <8904051324.AA23776@decwrl.dec.com>
Date: 5 Apr 89 13:24:00 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 68

rusty c. wright, agate!rusty@ucbvax.berkeley.edu writes:

>Also puzzling is the output of xdpyinfo when you run it on a uvax 3200
>with a 4 plane monochrome qdss:
> 
>Ultrix 3.0 DecWindows:
> 
>  depth of root window:    4 planes
>  number of colormaps:    minimum 1, maximum 1
>  default number of colormap cells:    16
>  preallocated pixels:    black 0, white 1
> 
>MIT qdss server:
> 
>  depth of root window:    4 planes
>  number of colormaps:    minimum 1, maximum 1
>  default number of colormap cells:    14
>  preallocated pixels:    black 0, white 1

I wrote a lot of the color support for the VAX server currently used on both 
VMS and Ultrix DECwindows, so I can tell you about that, although I can only 
guess about the MIT qdss server.

In the 8-plane Gpx, the cursor (which is really not software...it just
borrows a couple of colormap cells to determine its color) color is 
specified in colormap cells 254 and 255.  These colormap cells are hard-
wired to the cursor, although you can also use indices 254 and 255 in the
regular image.  I chose a somewhat different route than MIT for the 8-plane
system (yes, I know...I'm coming to 4-plane). What I did was specify that 
there are 256 colormap cells, but I always have 254 and 255 allocated 
private in the default colormap.  Thus, normally, one should never have a 
problem overwriting them.  If you need to use a non-default colormap, 
however, you are able to allocate 254 and 255.  The theory here is that you 
are going to screw up the colormap anyway so you probably have a good reason 
for doing it, and may well really need the colors.  In fact I heard from a 
lot of image folks that they really wanted it this way since their images
assumed 256 colors.  Oh, yes, one more feature that makes this more 
palletable:  When a colormap is installed, it does not actually write
undefined entries into the h/w colormap.  That means that if you don't
really use 254/255, it won't wipe out the cursor.

Now as promised to the 4-plane case:  In the 4-plane GPX, the same h/w
colormap is used, and it still has 256 entries.  The cursor is still hard
wired to 254 and 255.  That means that under any philosophy, the qdss server
is wrong to say that there are only 14 colors.  You can use 16 with 
impunity.

Note that this funny business with the cursor only happens on a VSII/GPX
and a 3n00/GPX.  On a VS2000 they put in some dedicated colormap cells for
the cursor.

> 
>The other thing that is curious about the output of xdpyinfo when you
>run it on the MIT qdss server on a monochrome 3200 is that it has 2
>visuals and the classes are PseudoColor and StaticColor rather than
>the expected GrayScale and StaticGray.
>--
> 

There is no way in hardware to determine whether you have a monochrome or a 
color GPX.  I suppose that the qdss server just assumes color.  In the VAX 
server you can specify it.  On VMS, you define a logical name.  I'm not sure 
how that part got implemented in Ultrix.  Probably a command line argument.  
In fact, you should probably check to make sure the MIT server does not also 
have a command line argument for selecting mono or color.

Burns