john@onecom.uucp (John Brinegar) (03/13/91)
I have been having philosophical discussions concerning colormaps in X, and
I am interested in receiving a dose of conventional wisdom on this topic.
I am currently working on a product that contains two separate X client
applications with 128 colors each (same 128 colors for both applications).
These 128 colors have to be settable (read/write) by the application. These
colors are all specified by their RGB values. I have tried several means of
achieving this goal:
1. Allocating 128 read/write (non-shareable) color cells from the default
colormap for each application. This does not work, because there are only
256 cells in the colormap, and some are already allocated by other
applications. This clearly is not a solution because of system resource
limits.
2. Creating a separate (identical) colormap for each application, and allocating
128 read/write color cells from the newly created colormap. This
solution has the familiar side effect of colormap swapping when the
mouse pointer leaves the application's window. This is a problem in our
environment because the colors in our application are critical to the
functionality of our product. However, this is only a problem when
the mouse pointer leaves either of the two applications (because the
applications have identical colormaps).
Advantage: Correct colors always available for each application.
Disadvantage: False colors when pointer outside of both applications.
3. Using XAllocColor() to try to get the exact colors we request in
each application from the default colormap. If our applications are the
first third party X applications up, the odds are very good that we will
successfully allocate all the requested colors (exactly as requested - by
RGB values). However, this is not always guaranteed - other complex,
many-colored applications may have all colorcells in the default colormap
allocated, and we have to settle for approximations. (See Xlib Reference
Manual).
Advantage: No colormap swapping
Disadvantage: No guarantees that exact colors will be available
For further information, these applications are running on an IBM RS/6000
running AIX V3.1 (3003 update).
Are there other alternatives for what I am trying to do, or do I need to choose
between the lesser of two evils (2 and 3)? Any help with this dilemma is
appreciated.
--
John D. Brinegar {att!uswat, uunet!dunike} !onecom!john
TelWatch Inc. (303) 440-4756 ekberg@asl.dl.nec.COM (Tom Ekberg) (03/13/91)
Since you state that both applications use the same 128 colors, why not share the cells in the colormap. More than one client can use a color cell, even if it is settable. In chapter 5 of the Xlib manual it states: Although you can change the values in a read/write color cell that is allocated by another application, this is considered ``antisocial'' behavior. The idea is to have one client try to allocate 128 colors. If it fails, it would look to see if the other client already allocated its colors, and then use those. By having the two applications cooporate you should be able to get by with needing only 128 color cells. -- tom, ekberg@asl.dl.nec.com (x3503)
marbru@attc.UUCP (Martin Brunecky) (03/14/91)
In article <1991Mar12.235227.28172@onecom> john@onecom.uucp (John Brinegar) writes: > >I have been having philosophical discussions concerning colormaps in X, and >I am interested in receiving a dose of conventional wisdom on this topic. > What about alternative: 4) Creating a private, writeable (pseudo color visual) color map. Allocating all 256 colors (or 16 for 4 bitplane system). Reserving the top 128 (8) colors for your colors. Copying the low 128 (8) colors from the default colormap into your private colormap. This gives you color cells you want, and significantly reduces the "technicolor" effect. In fact, it works pretty well if you only preserve (copy) something like 16-32 colors from the default map. Of course: - your private colors could go south if the focus moves out of your application. But at least your application would not destroy common controls (such as WM decorations) and the user will be able to navigate between applications. Also note that many servers do NOT change unallocated color cells when the colormap is swapped, so your "private" colors often remain in effect even when the default map is reloaded. - you may periodically update the copy of the default colormap in your private colormap (to reflect changes due to other apps). - you may consider a server which does NOT allocate colors using the bottom-up approach (I haven't seen one yet, but ...). There are (clumsy) ways to find out which color cells ARE currently allocated in the default colormap (depending on it's visual), so you can figure out how the server does it's allocation and locate your "private" cells appropriately. -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky {...}sunpeaks!auto-trol!marbru (303) 252-2499 (sometimes also: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
mouse@lightning.mcrcim.mcgill.EDU (der Mouse) (03/14/91)
> I am currently working on a product that contains two separate X > client applications with 128 colors each (same 128 colors for both > applications). These 128 colors have to be settable (read/write) by > the application. Which one gets to set them? How do the applications make sure that they both want the same values in all 128 slots at the same times, if they change? > 3. Using XAllocColor() to try to get the exact colors we request in > each application from the default colormap. I thought you said the colormap cells had to be read/write. XAllocColor allocates read-only cells. > Are there other alternatives for what I am trying to do, or do I need > to choose between the lesser of two evils (2 and 3)? One possibility comes to mind: have the first client to start up allocate the cells in the default colormap (or, if that's not possible, create a new colormap and allocate them there). This allocation is done on a separate connection created specifically for the purpose, with a close-down mode of RetainPermanent. Later clients find out about this through window properties. I don't think you can completely avoid possible problems in case some client uses XKillClient to free up your allocation. The first thing that comes to mind is to stash the information in a property on the root. While this will work, it is fragile in the face of XKillClient being used to destroy the allocations. (It would be nice if there were some way to specify that a property should not survive beyond some client's "destruction of resources" point, meaning either connection shutdown or XKillClient, as the case may be.) A somewhat more robust scheme would be to create a window somewhere, put the information on a property on it, and then put its ID in a property on the root. (The window should be 1x1 - as small as possible - to conserve resources and should probably never be mapped; it might even be completely off-screen.) This way, if the resources are destroyed either the window ID will be invalid or, if it gets reused, it won't have the magic property on it. Of course, the testing and setting of these properties has to be done with the server grabbed. This is unfortunate, but I see no way of getting around it. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu