chander@vitsun.UUCP (Chander Ahuja) (06/22/89)
Environment:
Xlib programming level.
SUN 3/4 with OS 3.5/4.0 (visual = 8-bit PseudoColor)
MIT X sun server
Q. What is the best way to accomplish this:-
(with portability across servers supporting 8-bit PseudoColor visuals)
Application draws three partially overlapping polygons (red, green, blue)
with an 'OR' operator.
Want the overlapping regions to exhibit the correct color (eg: color==white,
where the 3 polygons overlap) for this 'OR' operation, that is 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.
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.
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')
{-- i.e. producing similar results to what the server
produces for XAllocColor() requests, but now has to be
done with equivalent client code }
-- query the server for rgb of each pixel in colormap and carry
out the 'nearest' comparison
{-- too much server communication required.}
-- 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.}
I would like to be able to use XAllocColor() or something similar so that
client side code is not duplicating server code.
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 ??)
-- Other application go technicolor when cursor is in this
application
-----------------------------------------------------------------
Finally :=
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"
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.
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. OR
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"....?
III) How do "standard" UI's (OpenLook, Motif) intend to enforce their "look"
(see Open Look Functional Spec, Rev 15, chapter 9, para 5 - "...use of
color in the standard interface regions - the window background, ...")
on applications that require separate colormaps to support application
functionality (example trying to OR pixels) OR
is 'going technicolor' an application aberration that will be tolerated
for purposes of UI certification/compliance.
IV) What use is the 'OR' operator without predictable pixel values (which
can only be got by using a specific colormap, which leads to all the
other problems).
Any comments, suggestions, alternatives are welcomed. (Flamers - tone it
down, its hard to see your good points when you are passionate)
-----------------------------------------------------------------
I can make a couple of suggestions to start with :-
1. Extend the X color model to include "global" colorcells besides r/w and
r-only. Global cells will be "read-by-all/write-by-one" type cells.
That is only one client may allocate and store values into that cell, but
other clients can allocate the cell with the usual read-only mechanism.
2. Extend the XAllocColorCells protocol to allow "pixels_return[]" argument to
be (optionally) an input of the actual pixel values wanted AND/OR
the "plane_masks[]" to be (optionally) an input of the actual planes
desired. On return, the arrays will contain the Pixels which could
actually be allocated (same as now). An error to be returned when no
pixel or plane could be allocated at all.
----------------------------
Chander M Ahuja
Visual Information Technology
(214)-596-5600
email: {sun|...}!convex!vitsun!chander
Global Disclaimer:
Everything including the period and newline character at the end of this
sentence reflects my own perspective only.converse@EXPO.LCS.MIT.EDU (Donna Converse) (06/23/89)
> 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
rws@EXPO.LCS.MIT.EDU (07/03/89)
Application draws three partially overlapping polygons (red, green, blue)
with an 'OR' operator. Want the overlapping regions to exhibit the correct
color (eg: color==white, where the 3 polygons overlap) for this 'OR'
operation, that is the requirement is for particular pixels to represent
particular rgb values (upto 64 such "OR-predictable" values may be required
in this particular case).
Donna Converse has given you one scheme for this, if direct server support of
read-only allocation is required.
XAllocColorCells will do what you want, if you're willing to give up on the
read-only constraint. You want npixels set to one, and nplanes set to however
many independent OR bits you need. For your application, you should be able to
specify contig as False. As nplanes approaches the depth of the window, of
course, the request is likely to fail, and you may have to create your own
colormap.
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.
There's no server support for this if you use AllocColorCells, you'd have to
do it yourself by maintaining a mapping on the client side. What you might
be fishing for is either a mechanism to turn a read-write cell into a read-only
one, or a request like AllocColorCells that takes the RGB values and returns
read-only cells.