| Title: | DECWINDOWS 26-JAN-89 to 29-NOV-90 |
| Notice: | See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit |
| Moderator: | STAR::VATNE |
| Created: | Mon Oct 30 1989 |
| Last Modified: | Mon Dec 31 1990 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 3726 |
| Total number of notes: | 19516 |
In my application, I want to create a private colormap if I run out of colors in the shareable color map. I am creating the private colormap using XCopyColormapAndFree. This routine unexpectedly (but nicely) preserved the window foreground, background, border, and highlight colors as well as the colors black and white. In other words, I could not alter these pixel values by freeing them and allocating a new different color (even after having filled up all of the other entries in the private colormap). This is kind of nice - as it preserves the window colors (won't let you change window fg. and bg. to be colors which are very close to one another - which would make things difficult to read). If you keep allocating colors though, it will let you allocate colors in the spaces reserved for the cursor colors, which is kind of nasty, as it will mess up the color of the cursor. Can anyone explain to me why these routines, XCopyClormapAndFree and XAllocColor work the way they do (preserving those important colors, yet not the cursor colors). Also, can anyone tell me how I might also protect the cursor colors from being changed. Also, if I freed all of the colors in the private colormap - then did an AllocColorCells requesting all of the colors (256 on an 8 plane system) asking for non-contiguous, it returned succesfully, but the returned pixel values skipped over the 6 aforementioned special colors, and instead returned pixel values up to 261 (which is out of range) Can someone straighten me out on this please. Thank you. -Jonathan
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1946.1 | Two features and one bug | DECWIN::FISHER | Burns Fisher 381-1466, ZKO3-4/W23 | Wed Dec 20 1989 16:55 | 33 |
WelI can explain a lot of this, I think. CopyColormapAndFree copies
all cmap entries that you, i.e. your client, have allocated. This
includes read-only sharable colors. Each application has to allocate
its own bg, fg, highlight, etc since the application gets the color
values, not the index values of these told to it. Thus CCAF puts these
colors in the new CMAP. Since the application allocated these as
shared colors, it got the same pixel value that all the other
applications got. After CCAF, these pixel values still represent the
same colors, so other applications which are using those colors don't
go technicolor. I'm not sure about why Black and White should be
preserved. Somewhere, your application must have allocated them.
Regarding the cursor: Mea Culpa. I explicitly designed that as a
feature to work around a hardware misfeature. The thing is that
VSII/GPXes have the characteristic that the cursor shares colormap
entries 254 and 255 with the frame buffer. Thus, if you want to use
255 colors, you have to wipe out the cursor. What the code does is in
the default colormap, it allocates 254 and 255 so no one will ever use
it. However, because I got lots of screams from people who had images
which assumed 256 colors and no less, I decided not to allocate these
entries in non-default colormaps. This has kept most people happy
(till now). If you are developing a product, be comforted by the fact
that all the new color machines don't have the hardware misfeature.
All 256 entries are unencumbered. If you are doing something for
internal use, look for 254 and 255 and don't use them if you get them.
(Hack alarm!)
As to the last thing you mentioned, that sounds like a bug. Some part
of the colormap code apparently thought the color cells were
deallocated, while some other part of the code thought they were still
shared. Please submit a QAR.
Burns
| |||||