Subject: FVWM: more on color of resizing grid

From: [email-masked] (Jeff Magill)
Date: Thu, 3 Oct 96 11:01:35 PDT

>Actually, I've been meaning to ask a similar question:
>My background is also mostly black.... after running fvwm 2.0.41 for 
>several hours/days, the grid starts showing up as a different color.

I believe that the rubberbands (grid) changes color during your X session
because most of the colors you see are the result of just dipping into the
default colormap and grabbing whatever color happens to be there.
(Someone correct me if FVWM doesn't work this way).  So, as X applications
change the default colormap, the rubberband colors change.  (This may be
only applicable to PseudoColor displays--i.e. displays that have a limited
colormap, often 256 colors.)

The XOR operations are occuring on colormap INDEXES not RGB values.  The
screen is layed out in rows and columns of pixel values which are NOT RGB
values.  The pixel values refer to cells in the colormap.  These cells
contain the RGB value of a pixel and these RGB values of cells are under
control of whatever applications happen to be running.

As the rubberbands are drawn, each pixel value is XOR'd with the XOR value
and the result of the XOR is put in place of the old pixel value.  The new
pixel value refers to some color in the colormap index.  But, FVWM doesn't
change the entire colormap so that the result of the XOR is a predictable
color (doing so would be a bad idea).  So, drawing the rubberband is
basically the same as drawing a line of random colors from the colormap.
You see different colors in the rubberbands because the colors in the
colormap change.

It's easy to setup an XOR value the results in a certain pixel value when
applied to a certain pixel value.  E.g. you can set up the XOR value to
always change white pixels to black pixels and vice-versa.  To do that,
you look up the pixel values for white and black and compute the XOR value
(actually, I think you simply XOR the two pixel values together to get the
right XOR value).  But doing that, you still don't know what color will
result when XOR'ing the XOR value with some other pixel value on the screen.

I think that on a lot of displays, the first two cells in the colormap
are black and white.  That's why the XOR value of 1 works well when you
have a lot black pixels in your root window.  I.e. the XOR operations
look like this (on an 8-bit display):

  draw rubberband:   00000000 XOR 00000001 = 00000001 (black)
  remove rubberband: 00000001 XOR 00000001 = 00000000 (back to white)

Jeff
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].