marbru@auto-trol.UUCP (Martin Brunecky) (08/29/90)
Writing a modest X applications, I am running into problems with color
map entries allocation. For known reasons, I am trying to use the
default colormap. Since I need LOTS of colors, I have to FREE my
colors once not needed (yes, displaying images...).
The problem is that using bunch of widgets (and may be even UIL/Mrm
GOD forbid -), my application contains several "customers" issuing
XAllocColor and other color cell allocation calls.
When I allocate my color, I never know if the pixel returned to me
is a "brand new one", or just a "clone" of a pixel already alocated
from MY CLIENT by some widget (string-to-pixel converter) or something else.
Thus, issuing XFreeColor on such a pixel, I am running a BIG risk that
I will free a pixel that is still in use.
I can use writeable color cells - those will be unique to my allocation
request. But with this approach I can lock-out other clients, leaving
them with a very small palette of read-only color cells. I don't want
to take this approach either.
Looking at Xlib specifications and the X protocol specification suggests
that I am out of luck, unless I overload Xlib color allocation functions.
Difficult to do, especially when Xlib is a shareable image provided by
DEC(DECkWindows-) or Sun (ClosedWindows-).
Did anyone struggle with the same problem ?
Did I overlook something ?
Any suggestions ?
Any plans to provide color allocation caching (similar to GC) in X11 R5 ?
Please, H E L P !!!
(I promise not to flame on UIL for at least one week !)
--
=*= Opinions presented here are solely of my own and not those of Auto-trol =*=
Martin Brunecky marbru@auto-trol.COM
(303) 252-2499 {...}ncar!ico!auto-trol!marbru
Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404 ekberg@ti-csl.csc.ti.COM (08/30/90)
Martin Brunecky writes: > When I allocate my color, I never know if the pixel returned to me is a > "brand new one", or just a "clone" of a pixel already alocated from MY > CLIENT by some widget (string-to-pixel converter) or something else. Thus, > issuing XFreeColor on such a pixel, I am running a BIG risk that I will > free a pixel that is still in use. > > I can use writeable color cells - those will be unique to my allocation > request. But with this approach I can lock-out other clients, leaving them > with a very small palette of read-only color cells. I don't want to take > this approach either. It appears that you were looking at an R3 or older version of the X11 protocol specification. A change made to the R4 protocol specification says the following with regards to the FreeColors request; Similarly, a read-only entry is not actually freed until it has been freed by all clients, and if a client allocates the same read-only entry multiple times, it must free the entry that many times before the entry is actually freed. This means that your client, at multiple levels, can allocate the same pixel more than once. When it comes time to freeing the pixel, each level freeing that pixel will work as expected. There is no need to shadow the FreeColors request to handle this case. -- tom (aisle C-4Q), ekberg@csc.ti.com