Conference bulova::decw_jan-89_to_nov-90

    Projects,  I think you really ought to get cozy with some X and
    DECwindows documentation...
    
    The answers to questions you asked is in the documentation.
    
    In general, given a pixel value, XQueryColor, returns RGB values for
    it.
    
    In general, given a widget, DwtNbackground, DwtNforeground,
    DwtNhighlight, and other resource names will return the pixel value for
    the color indicated.
                            

	SDSVAX::SWEENEY "The Finite Voyage"

	I have pixel values... what I am looking for are the index numbers
	to a color map entry specifically the default color map. These numbers
	are the numbers used in the Xor function to derive the new color
	or colormap entry.

You should not need color map index values at all to do what you want to do.
(Unless I'm missing something.  The direction this discussion has taken has
been very confusing to me.)

I think that what you want to do is something like:

(1) Create a GC with a plane mask and function as follows:

    values.function = GXinvert;
    values.plane_mask = background_pixel ^ foreground;
    flipgc = XtGetGC (w, GCFunction | GCPlaneMask, &values);

(2) Use XFillRectangle with this "flipgc" to flip colors.  If you want
to draw a line, make the rectangle very narrow.  You may also be
able to use the GC in an XDrawLine call.

-steve-

    re .-1
    
    Maybe you got lost. I did the same thing a few minutes ago. The
    discussion on drawing and erasing lines is in 1902. 
    
    re. .0
    
    You can use macros like BlackPixel and WhitePixel (see the
    documentation that .1 refered to) to get black and white on 
    any workstation.
    
    As for any other color cell in the color map - nothing is 
    guarenteed (or however that's spelled). What cell is used
    by what depends on a number of things and you can never be
    sure that an application will use the same pixel value to
    store the same color info twice).
    
    Ron 

    Now, I'm going crazy...
    
    First of all "a color map entry" isn't a meaningful concept to a client
    application.  "Color map entries" are things that servers and server
    implementors worry about.
    
    The term that is used by a client is "pixel value" and pixel values are
    only meaningful when associated with a "color map".  Many X routines
    manipulate RGB values and pixel values/color maps.
    
    One color map, the default color map exists.
    
    Their is no "guaranteed" association between the pixel values and their
    RGB values.  There is no "guaranteed" association between RGB values
    and background/foreground values except through the routines at
    runtime.  You must call XQueryColor, you must call XtGetValues.  No
    shortcuts.
    
    In fact, you can never just save pixel values, you must save the
    associated color map data (ie the RGB values for each pixel value you
    want to save), even if you use the default color map.

    
    > Now, I'm going crazy...
    
    Welcome to the club...I've been a member for some time now!
        
    > First of all "a color map entry" isn't a meaningful concept to a client
    > application.  "Color map entries" are things that servers and server
    > implementors worry about.
    
    A pixel value is an index into a color map. In other words it is
    the address of a color cell (i.e., an entry in the color map). An
    application can allocate a color cell in the color map (in which
    case it is returned a pixel value that is the address of that color 
    cell) and can store color intensity information into that cell.
    
    > You must call XQueryColor, you must call XtGetValues.  No
    > shortcuts.
    
    XQueryColor will give you the RGB info for a pixel value, but isn't
    it a lot of work to go through to find blue? It is not real clear
    from PROJECTS (who are you by the way?) question why he/she wants
    to know 'where a particular color is in the colormap'. Maybe a more
    detailed explanation of the problem is needed. BlackPixel and 
    WhitePixel, by the way aren't shortcuts. They are a part of Xlib.
    I assume that was what you were talking about since my note was
    the only one that seemed to imply a shortcut?
    
    > In fact, you can never just save pixel values, you must save the
    > associated color map data (ie the RGB values for each pixel value you
    > want to save), even if you use the default color map.
    
    Actually you if you allocate contiguous private color cells you
    can store the base pixel value with the pixel values from the image.
    When you read the image compare the stored base value against the
    current base value, compute the offset, and use XAddPixel to add
    it (a positive or negative value) to the pixels values read from
    the file. I've been using this with success on all of our workstations.
    Of course it only works if the pixel values are contiguous.
    
    Ron

    
    Actually a pixel value *isn't* a colormap index.  Colormap indexes are
    a hardware concept found in COLOR MAPPED systems.  However, there are
    also systems which implement color differently, static color, static
    grey, truecolor and directcolor come to mind.  Of couse many of these
    can be treated in many respects like a color mapped system - but they
    may not be.
    
    The pixel value returned from the default firefox visual is a 24-bit
    value which contains 8-bits of red, green and blue and NOT a index
    into a colormap, a "colormap" would need to have some 16 million
    indexes and could only map 16 million colors anyway!
    
    In general, unless you are strictly using practices which ask the
    server for the pixel values of the colors you wish to use and then
    ONLY use those colors/pixles and DO NOT use drawing functions which do
    logical operations of the source/destination pixels, then your code
    *must* have special-case logic to handle at least the distinction
    between a static and writable map.  Even if it ignores the fine
    distinctions with systems using DIRECT color or non-regenerative
    bitonal (MFB) output.
    

	I'm back...

	To reiterate the problem ...

	   (drawing & erasing lines using GXxor GCFunction and at
	    The same time retaining the color of the rubber band 
	    line I am drawing and erasing... which is blue)

	The rubber band line I am drawing is erasing fine but the line is
	taking on an unpredictable (dark) color which is the result of the
	GXxor function (the xor of the src & dest pixel values).

	Anyways I thought I could find a short cut to display the color blue
	by finding an inverse or something to that effect... or some formula
	manipulating pixel values to be able to display a line of a desired 
	color, erase lines as the rubber band moves, retain the color of the
	line without having any care about what color is currently on the 
	part of the screen you are displaying.

	I appreciate the replies and will take a look at them closely.
	Let me know if someone finds a shortcut.


	P.S. Would pixel depth be a factor here? 

	A further note...
	What is currently on the screen is unpredictable
	yet a determining factor of the outcome of the desired color.

    re: .8
    
    Granted a 24 plane truecolor workstation does not have a colormap
    However the X Window System developed the concept of 'logical' color 
    maps to allow the fact that some workstations do have hardware color maps
    while some don't to be transparent to us.
    
    We can still think of the firefox as having a color map  - although
    a logical one (It also has an 8 plane pseudocolor visual which supports
    logical color maps. Here like in other pseudocolor displays the
    pixel value is an index into that logical color map. But it is still
    a 24 plane system that doesn't contain a color map!) with pixel
    values that index that map. It just so happens that with the truecolor
    visual the pixel value actually contains color information whereas
    in a pseudocolor or directcolor visual it does not. 
                         
    Ron

I think I understand what Projects is asking.  See if I am reiterating this
correctly:

You have some windows that are already created.  You would like to find out
what their background pixel values are, and what color those represent so that
you could calculate a pixel value and an xor value such that when you do the
xor you get the pixel value.  You then stuff the pixel value with the a contrasting
color.

Right?

In any case, Fred is right...you have to be very careful to make sure that whatever
you do will work on TrueColor, StaticGray, GrayScale and all those other things
as well as PseudoColor.

In general, there is no fixed pixel value that is used by an application.  You
may be able to figure it out for a particular application, or if you are inside
the application you probably can find it.  However, worse than that is the problem
that you can't ask X to allocate you a particular index value.

The "right" way to do this with the existing X protocol is to do it all in the
applications.  When you allocate the colors the application will use, allocate
them all together with XAllocColorCells, and also specify one plane in that call.
Then set up the colormap so that all the pixels which come back are the colors
you normally want them to be, and that all the pixels which come back, or'ed with
the plane value that comes back are the contrasting color that you want when
your stretchy box or whatever goes over.  Then draw the stretchy box with the
with the plane mask set to the plane value returned by AllocColorCells, the
function set to Copy and the value set to 0xffff when you want to draw in the
alternate color, and 0x0000 when you want to return to the original color.

This method works great, but is (1) very wasteful of the colormap, (2) works
only on PseudoColor (and DirectColor), and (3) requires that all the colors
be allocated at once.

A second method is to do a GetImage on the bits underneath where you are
drawing, and then draw.  To restore the original, do a PutImage back.  This
answers all the objections in the previous method, but has a couple disadvantages:
(1) it is probably VERY slow, although no one that I know of has tried it and
(2) if you are going over multiple windows, you may have a problem, since each
window could conceivably be using a different colormap, and besides the protocol
specifies undefined results for doing a GetImage from multiple windows of
different depths.

The third, and probably best method is for someone to define and implement an
extension so the knowledge of the right thing can be built into the server and
done the most efficient way for the particular hardware in question.

Burns

    re: .-1
    
    > The "right" way to do this with the existing X protocol is to do it all in the
    > applications.  When you allocate the colors the application will use, allocate
    > them all together with XAllocColorCells, and also specify one plane in that call.
    > Then set up the colormap so that all the pixels which come back are the colors
    > you normally want them to be, and that all the pixels which come back, or'ed with
    > the plane value that comes back are the contrasting color that you want when
    > your stretchy box or whatever goes over.  Then draw the stretchy box with the
    > with the plane mask set to the plane value returned by AllocColorCells, the
    > function set to Copy and the value set to 0xffff when you want to draw in the
    > alternate color, and 0x0000 when you want to return to the original color.

    > This method works great, but is (1) very wasteful of the colormap, (2) works
    > only on PseudoColor (and DirectColor), and (3) requires that all the colors
    > be allocated at once.

    This is what I've been trying to describe in note 1902. I was not
    however aware that no mechanism has been built into X to allow its
    use on the firefox (probably because I'm using the 'less expensive
    models' and haven't had easy access to a firefox). Be that the case,
    yuck....

    Is the only current way to do this on the firefox your method 2?
    As conincidence has it I was going to test a program I have on a
    firefox tomorrow. It uses overlays for a grid which is the same
    concept as you describe above. I am however using Xor rubberbanding
    since in this particular application the color changes don't bother
    me (guess I'm used to it from other platforms). 
    
    What you appear to be saying is that it isn't going to work using
    a truecolor visual. How about using the firefox's pseudocolor
    visual? 
            
    Ron
    

Sorry...yes the problem is not the firefox hardware.  It is any TrueColor visual.
The FF 24-plane version defaults to TrueColor.  If you use the PseudoColor
visual, it will be fine.  As long as you are only dragging within the
PseudoColor window.

Burns

Remember when you use a non-default visual, there are a number of window parameters
what you have to specify which you normally allow to default.  Otherwise you
will get a Match error.  For example, colormap, background pixel/pixmap, border
pixel/pixmap.

Burns

    Could you give me a quick list? I've had one attempt at testing
    my program on a firefox (which translates that I finally found one
    and had about 30 minutes to play with it). 
    
    In the program I use XMatchVisualInfo to search for an eight plane
    pseudocolor visual. If I find one I check to see if it is the default.
    If so I use the default color map. If not I create a color map which
    installed the program gets the input focus.
    
    I got no errors, but I would up with a black windows and no drawing
    colors (probably all were set to black).
    
    Anything sound wrong here?
    
    Ron

	I found a short cut...

	I found what colormap entry values were attached to the color of my
	widget and defined a 8 bit result equal to the desired color. I then
	figured what the widget color had to be Xor'ed to to come up with the
	desired color. I assigned this value to my foreground color of my GC
	and it worked.

	Ideally I would like to come up with a strategy that is independant
	of the current values of already displayed pixel.

	Does private color cell fullfill this need?

	Much appreciated

    Has anyone got a working example of how to use the FF 8-plane
    pseudocolor visual?  I have no problem with direct and truecolor,
    but the 8-plane is a no-go... is it possible at all to create a
    PIXMAP for that visual?
    
    In any case, XUIS will handle all of these details just fine (except
    for that darned FF 8-plane visual) and even give you back complement
    mode.
    
    _Fred
    

.17

I want to make sure I understand what you did.  You found a pixel value
which when Xor'ed with your background pixel value results in your foreground
pixel value.

For the most part this sounds reasonable.  However, it will yield undefined
results when Xor'ed with your foreground pixel.  This will be particularly
noticable when there is a large expanse in the foreground pixel.  It will
be further compounded if you use several different pixel values for
different parts of your foregound.  If these problems don't apply, then
you have found a reasonable solution.

Dick

        re - .19

                Forget about background & foreground pixels.

        I found a pixel value (which happens to be the customized color of
        my widget... don't care if it's background or foreground) of the color
        I made my widget. I  was trying to make my software display a blue on
        the screen so I set blue as the result of my Xor operation.

                pixel value i found
        XOR     ???????????????????
        ----------------------------
                blue

        I then solved for ???????????? and set that as the color I write to the
        screen which happens to be a foreground. I try not to think of
        foreground/background when I write colors to screens I only think
        about pixel values. After all thats all they are.

        If the user customizes the color of their windows thru the session
        manager pull down menu... I am assuming that this will throw off
        my solution here.

        Ideally one would want to do this operation independant of the current
        state (color) of the screen. Does anybody have suggestions. Can private
        color cells fulfill this need??????????????????????????????????

        Much appreciated

Remember that just about any widget has at least 2 pixel values.  One is used
for the window background.  The other is used for drawing to the foreground.
So, if you want to use a scheme which allocates few colors and has no
restrictions on their relationship to each other, you need to decide whether
you want to be visible when xor'ed with the foreground pixel or the background
pixel.  Implementation wise, it does not matter which one you choose.

Now, if you want to draw some 3rd color (say blue  8^{) or even if you want the
xored stuff to produce the foreground color.  You should use XAllocColor to get
the pixel value for the color you want and then find the pixel value
which when xor'ed with the pixel value where you want to draw (say background)
yields blue.  If you are drawing over a region which will be clearly a mix of
foreground and background, you will get blue on one of them and some undefined
color on the other.  Unless you want to do the more sophisticated playing with
XAllocColorCells you are stuck with that.

Now, the next step is what can you do about user customization.  I would
lookup the color to be used in xor drawing and the background (or foreground)
colors from Xrm and then calculate at run-time the pixel value necessary to
xor between them.  This lets the user decide on ALL of the colors.

Dick
Was the above clear.  You can do what you described you just have some
limitations.

    
    .18 
    	Fred,
    		I have an example that uses the PseudoColor Visual on the
    FF. I sit on row of cubes across from you. Stop by when you
    get a chance and I can show you. Pole J10.
    
    Dave