Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!bloom-beacon!EXPO.LCS.MIT.EDU!converse
From: converse@EXPO.LCS.MIT.EDU (Donna Converse)
Newsgroups: comp.windows.x
Subject: Re: Using Colors in the X environment
Message-ID: <8906221905.AA14144@expo.lcs.mit.edu>
Date: 22 Jun 89 19:05:11 GMT
References: <8906212236.AA27410@sun.com>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: X Consortium, MIT Laboratory for Computer Science
Lines: 154


> Q. What is the best way to accomplish this:-
>  (with portability across servers supporting 8-bit PseudoColor visuals)
>
>  ... the 
>  requirement is for particular pixels to represent particular rgb values
>  (upto 64 such "OR-predictable" values may be required in this particular
>  case).
>  In other parts of the application, don't care which pixel represents the
>  desired color values (for menus and such), but preferably want to use
>  shared pixel allocation to minimize color-cell consumption.

You'd like to have up to 64 contiguous cells in the default colormap, 
allocated read-only and defined by your application.   

You can do this:
Allocate read/write all free cells in the default colormap of the screen.
Sort and search through the returned pixel values to find a contiguous 
subset of the required length.  Individually, for each pixel value in the
subset, free the read/write allocation, then make a read-only allocation
request for the desired rgb value.  If this request does not return the
pixel which was just freed, free the undesired read-only pixel,
allocate a single pixel read/write, (which you must check again to see
if it is the same pixel value that you earlier freed), and store the
rgb value into this read/write cell.  (This is likely to happen in the
case of black and white.)    Finally, when you have defined all
the cells you need, free the extra cells that you allocated.

> However :-
> 
>   1. If simple "read-only" pixels for r,g,b are obtained using default
>       colormap,
>          -- the actual pixel value and the resulting ORed result is
>            unpredictable.

No, we *can* get predictable pixel values and shareable allocations this way.
You are referring to the unpredictability of which pixel will be returned
by a read-only allocation.   If every cell of the colormap
except one is allocated, we force the implementation to return either 
the free cell, or, a previously allocated cell of the same rgb values.
We can recover the free cell with a read/write allocation, as outlined 
above.

>   2. If a colormap is allocated (AllocAll) and predictable color ramps to
>      support the 'OR' are stored in the colorcells, this colormap can not
>      be used in other parts of the application for "read-only" allocation
>      of colors except by (one of):
>
>           -- doing an inverse calculation to figure out where the required
>              color is loaded in the colormap (including the headache of
>              trying to figure out 'nearest')

True, and this is only worth considering if you can guarantee that the 
owner of the read/write allocations will not change the rgb values.

>                  {-- i.e. producing similar results to what the server
>                      produces for XAllocColor() requests, but now has to be
>                      done with equivalent client code }

XAllocColor returns the closest rgb supported by the *hardware*, not the
closest rgb currently available in a colormap.   They are not equivalent.

>          -- query the server for rgb of each pixel in colormap and carry
>             out the 'nearest' comparison 
>                 {-- too much server communication required.}

Why query the server if the information is already available in another
part of the application?  I agree, too much server communication.

>          -- use the default map for the rest of the applications "read-only"
>             needs and the new colormap for these 'OR' window(s) only.
>                 {-- leads to the application's windows going technicolor
>                     dependent on the cursor position.}

Not desireable, expecially if the 'OR' stuff needs <= 64 cells out of an
8 plane pseudo-color visual.

>      I would like to be able to use XAllocColor() or something similar so that
>      client side code is not duplicating server code.

It is a mistake to provide a way for applications which need
cells in the colormap with unchanging color definitions 
to rely on another client not to write in the cell, when that other client
allocated the cell read/write precisely so that it has the freedom to 
dynamically change the color definition.

>   3. If a colormap is allocated (AllocNone) followed by colorcell allocation
>     for All (256), then a StoreColor for the desired (64) colorcells and
>     finally a FreeColorCell for the rest of the cells (192) allowing a single
>      colormap to be used for both r/w and r-only allocations in the
>      application.
>      Then:
>         -- None of the 64 r/w entries are usable as "read-only" even though
>             the client is the same for both the "read/write" and "read-only"
>             requests. (BTW. why is this a restriction ??)

When should a read/write allocation be regarded as a read-only allocation?
Answer: when it is guaranteed never to change.  If that is the case, then
it should not have been allocated read/write.

>          -- Other application go technicolor when cursor is in this
>             application

Right.

> I) these are the requests I would ideally like to make:
>
>  a. "Give me Pixel [[ N ]] (if available) as a read/write cell" followed
>           by "Store XYZ as the rgb value of Pixel N"

Requesting a specific pixel, if available, to be allocated as a read/write cell,
is a useful idea, but, you can manage to do this with the existing protocol.
What do others think of this?

>   b. "Give me a read-only Pixel containing XYZ rgb value [[ and include
>          in the search-list all of MY cells including read/write ones ]]"
>
>  the parts enclosed in [[ ]] are the parts of these requests not specifiable
>  with the current protocol.

I object to allowing read/write cells to be given out in response
to read-only requests.

> II) Can I make a colormap (the new one) the "default colormap" of the
>    screen such that other applications that do a AllocColor using the
>    macros DefaultColormapOfScreen() / DefaultColormap() will utilize this
>    new colormap.

No

>    how does my client tell other clients (started after) which colormap to
>    use BEFORE they start requesting colors for widgets...does the ICCM provide
>    a "startup" protocol such as "USE_COLORMAP_AS_DEFAULT"....?

The problem here is one client presuming to tell other clients what to do.
The ICCCM does not provide this.

> IV)  What use is the 'OR' operator without predictable pixel values (which
>     can only be got by using a specific colormap

Have you considered the case that RGB_DEFAULT_MAP is already defined,
before your client starts up, in the default colormap -- defined read/only,
with perhaps 125 entries?

> I can make a couple of suggestions to start with :-

I commented on these in section I, above.


Donna Converse
converse@expo.lcs.mit.edu