Path: utzoo!attcan!uunet!ginosko!bbn!csd4.milw.wisc.edu!cs.utexas.edu!tut.cis.ohio-state.edu!bloom-beacon!vitsun.UUCP!chander From: chander@vitsun.UUCP (Chander Ahuja) Newsgroups: comp.windows.x Subject: Using Colors in the X environment Message-ID: <8906212236.AA27410@sun.com> Date: 21 Jun 89 22:36:51 GMT Sender: daemon@bloom-beacon.MIT.EDU Organization: The Internet Lines: 127 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.