mtoy@xman.sgi.COM (Michael Toy -- The S.G.I. XMAN) (11/03/87)
In the porting layer document, pg. 25 a function pScreen->GetStaticColormap
is described, however there is no GetStaticColormap function in the screen
structure. There is a routine in server/ddx/cfb/cfbcmap.c called
cfbGetStaticColormap, but it is never referenced.
I'm no xpert, but I am wondering what the scoop is here. As far as I can tell
the correct way to set build routines for a server on a static color display
is to:
Write your own CreateColormap routines hooked in as pScreen->CreateColormap
which loops through each of the colors in the static map, calling AllocColor
with appropriate rgb values.
(reading on in porting layer document 5.2.7.2 seems to confirm this)
So is this GetStaticColormap a dinosaur or am I missing something
--
Michael Toy, secret identity: the XMAN at Silicon Graphics
Someday: mtoy@xman.sgi.com For now: {ames,decwrl,sun}!sgi!mtoypaulsh@shark.tek.COM (11/04/87)
> In the porting layer document, pg. 25 a function pScreen->GetStaticColormap > is described, however there is no GetStaticColormap function in the screen > structure. There is a routine in server/ddx/cfb/cfbcmap.c called > cfbGetStaticColormap, but it is never referenced. > > I'm no xpert, but I am wondering what the scoop is here. As far as I can tell > the correct way to set build routines for a server on a static color display > is to: > > Write your own CreateColormap routines hooked in as pScreen->CreateColormap > which loops through each of the colors in the static map, calling AllocColor > with appropriate rgb values. > > (reading on in porting layer document 5.2.7.2 seems to confirm this) > > So is this GetStaticColormap a dinosaur or am I missing something > -- > Michael Toy, secret identity: the XMAN at Silicon Graphics > Someday: mtoy@xman.sgi.com For now: {ames,decwrl,sun}!sgi!mtoy I can only offer a guess. You are right that it no longer (never did?) exists in the screen structure. It may have served a purpose when the cfb server was being implemented with the -DSTATIC_COLOR . However I find no current reference to the routine. If you implement the routine, it can be used in your own ddx routine pScreen->CreateColormap, to get the "appropriate rgb values" to initialize a static colormap that is being created by the server or a client. This may have been its intention. However note that the cfb implementation of GetStaticColormap returns the Screen Default ColormapStr. This means that the default colormap would have to be created and assigned first before this routine was called. If you implemented it to simply return a hardcoded static colormap or one that is initialized by probing the hardware (and possibly command line options) then this restriction would not apply to your use of the routine. I think the most interesting "server implementor lesson" is that the authors of the cfb routine assumed (intended?) the screen default colormap to be static. This makes sense. It also suggests that all servers should offer at least one "Static" class visual per screen so the default colormap for that screen can be created as a static (StaticGray, StaticColor, or TrueColor) colormap. Paul Shearer M.S. 61-277 Tektronix, Inc. P.O. Box 1000 Wilsonville, OR 97070-1000 W (503) 685-2137 H (503) 224-3536 tektronix!shark!paulsh
todd@GRANITE.DEC.COM (Todd Newman) (11/04/87)
The Porting layer document is, alas, a palimpsest. GetStaticColormap is one manifestation of an earlier version all signs of which have not successfully been obliterated. It used to be used, until we found a more elegant solution. The function need no longer be documented and there's no reason to have the code in CFB. By the way, the same sort of confusion is at the root of your ListInstalledColormap bug. You're right, ColormapPtr is a pointer to a ColormapRec, not to a Colormap. The documentation is wrong. /tdn