Conference bulova::decw_jan-89_to_nov-90

Why do they care which entries DEC chooses to use?  A correctly-implemented
X application shouldn't worry about such things.   The application
requests colour cells, and it will be given ones that are available.

First, off, any application in X that depends on particular numeric pixel
values in the default color map mapping to particular RGB values is broken.
X does not guarantee this.  That is why there's BlackPixelOfScreen,
WhitePixelOfScreen, and the whole elaborate set of routines to allocate
named colors and RGB valuea and to share colors.  If you want to use particular
numeric values, you must use a private color map.

I don't know why specifically the VS3200 and VS3100 allocate the particular
pixel values that they do, but I suspect it has to do with the display hardware.

I can think of no reason why DECwindows should be doing color image displays
slower because pixels 254 and 255 (say) are being used rather than 0 and 1.
My guess is that it's their own code that's slowed down.

--PSW

    To answer the question posed in reply 1 & 2 - The customer is using
    128 colors which change quantitatively every 1/30th of a second, hence
    they can not use named colors. The only way they know of to get this real
    time responce is to use X$INSTALL_COLORMAP to install their own
    private color map. For this reason, it is very important for them
    to know which colors xwindows needs for its own use, otherwise,
    they will not know where to store their colors. This is
    an OEM application and the customer needs to know DEC philosophy
    for implementing x-windows on future releases of the VAXstation.
                             

RE: .3

In that case, they should create their color map with AllocNone and then use
XAllocColorCells asking for 128 pixel values and no planes.  They then should
use the pixel values that are returned.

Once again, in X, you are not allowed to make assumptions about what are valid
pixel values for a colormap.  It will vary depending on the hardware.  Any
program that makes such assumptions is broken.

--PSW

    I'm not sure there's a meeting of the minds here yet.  "x windows"
    doesn't really require any colors.  Screens have a _default_colormap_
    and typical applications allocate cells out of the the default
    colormap.  The number of entries and their RGB values in the default
    colormap can't be determined in advance by the client.  If the default
    colormap won't do, then X provides other methods.
    
    Other notes with good tutorial information about colormaps are 1026
    and 1052.  It's important to understand what the default colormap is,
    what a private colormap is, and what a standard colormap is.
    
    Programmers of well-behaved applications remember that clients and
    servers are separate, and many applications must ask the server for
    information about itself rather that assuming a specific environment,
    this goes for screen dimensions, colors, and other aspects that may be
    expected to change from server to server.

RE: .5

There is another little wrinkle, and it is what .0 is running into.  The server
preallocates some cells for use with the mouse cursor.  Some workstation models
use pixel values 255 and 254 for this purpose (or was it 252 and 253? I forget).
Others use 0 and 1.  In either case, those values aren't available for
application programs to allocate.  I think .0 is complaining that the values
aren't consistent across all our workstations--they're dependent on the 
exact hardware involved.

The X architectural answer to this question is, yes, that's true, but it doesn't
matter because you are supposed to ask the server for pixel values to use,
anyway.  You aren't allowed to just assume that certain pixel values are valid,
precisely because the available values vary from platform to platform.

--PSW

To expand a little bit on what Paul said:

You should use XAllocColorCells or XAllocColorPlanes depending on what Visual
type you get.  If you need pixel values which are guaranteed to have a certain
number of bits in common (for logical operations on pixel values) then use
the planes argument in XAllocColorCells.  I am not sure about the details
of doing this with XAllocColorPlanes.

See _X_Window_System_C_Library_and_Protocol_Reference_ by Scheifler, Gettys and
Newman.  Section 5.1.2

Dick

RE: .7

Another option, for use with the TrueColor visual on the Firefox, is to call
XAllocColor.  XAllocColorCells won't work when the "colormap" is read-only, as
is the case with TrueColor.

--PSW