davef@sfsup.UUCP (C.D.Francis) (02/23/88)
We have encountered several problems while writing the Pseudo colormap software for our server. I'd like to know if anyone else has run into these problems and what the've done about them. *** Writable vs Read-only Colomaps *** The protocol document states that when a colormap is create "the colormap entries are undefined for classes GrayScale, PseudoColor, and DirectColor; for StaticGray, StaticColor, and TrueColor, the entries will have defined values," Why is it then that all server code supplied with the sample server, dealing with writable colormaps, allocate a black and white color cell? We have implemented our server to provide no default entries for our PseudoColor visual (has anyone else?). This works because most of our client software allocate a black and white pixel anyway. However, on our system we can also create a colormap and use all of the entries if need be. *** XAllocColor() *** For StaticColor (and StaticGray, TrueColor) XAllocColor() will return the pixel value for closest color supported by the hardware for the requested rgb value. The pixel is allocated read-only and can be shared. For PseudoColor (and GrayScale, DirectColor) XAllocColor() will return the pixel value for closest color supported by the hardware for the requested rgb value only if it is already in the colormap or there is room to put it in. Otherwise it returns FAILURE. The pixel is allocated read-only and can be shared. Many (most?) applications just want several distinguishable colors close to what they ask for (the StaticColor case). The PseudoColor case makes this difficult to do. 1) The application must be aware of the number of color cells available and choose its requests based on this information. If for example you are trying to generate a spectrum of colors and you blindly ask for 256 color hues but your hardware only supported 16 colors, you would get 16 shades of red (assuming you are the first application to run) and 240 failed requests. This strategy would work fine with a StaticColor colormap. Thus, all applications that want to deal with color must have logic to check the supported visuals and "do the right thing" whatever that is. 2) Knowing the number of color cells is not enough since other application may have run before you and filled up the colormap with their requests. Unfortunately, even though these cells may be read-only (ripe for sharing), the application would need to be able to identify the set of cells that are read-only (how?) and then use some form of best match algorithm (least squares as in the server?) to determine which pixel to allocate. Even so by the time the XAllocColor call is made the pixel may be freed and realloced by some other application! 3) Thus, it seems, all clients must create their own colormap to be assured of available resources (or use a toolkit to do this for you). Unfortunately, strategies for installing colormaps (or telling a window manager about a colormap to be installed when you get the focus) is still vague. Is this really true? It would be nice if XAllocColor() would add the color entry if space is available and otherwise give you the closest available (read-only) pixel in the colormap. Also it would be nice to have a XAllocColors() to avoid numerous round trips to the server. *** Getting the correct visual *** Are people using XGetVisualInfo() and XMatchVisualInfo() to insure they have the correct visual? Most of the software that I've looked at so far (that which came with the sample server or appeared on the net) assumes a default writable (PseudoColor) colormap. Are people aware of the behavioral differences Dave Francis AT&T End User Group 190 River Rd Summit, NJ 201-522-6409 ihnp4!attunix!davef in XAllocColor (see above) when using StaticColor vs PseudoColor?