Re: XForms: Wrong colors on Solaris

Steve Lamont (spl@szechuan.ucsd.edu)
Thu, 15 Jan 98 07:08:35 PST

To subscribers of the xforms list from spl@szechuan.ucsd.edu (Steve Lamont) :

> > Are you converting the FL_COLOR to a pixel value using fl_get_pixel()?
>
> I use the fl_set_foreground(GC, FL_COLOR) which should make the pixel
> conversion.
>
> > Well, not exactly. XForms tries to figure out the "best" Visual class
>
> > and use that when it starts up.
>
> Should I set the XForms visual to the X server default with a command
> option -visual Default or with fl_set_visualID? Where are the values
> for id defined?

The VisualIDs are basically intrinsic to the server. You can fish
this info up with

xdpyinfo

or there are Xlib call to get the same info (XGetVisualInfo() or
XMatchVisualInfo()) but you probably don't need to do this.

The Visual classes are defined in X.h:

/* Display classes used in opening the connection
* Note that the statically allocated ones are even numbered and the
* dynamically changeable ones are odd numbered */

#define StaticGray 0
#define GrayScale 1
#define StaticColor 2
#define PseudoColor 3
#define TrueColor 4
#define DirectColor 5

I went to the archive to look up your previous posting and I noticed
one thing that I managed to overlook in my last reply. You say:

> Most of my drawing is with Xlib functions. I set the foreground and
> background for the GC using FL_COLORs and then draw lines/text or copy
> a pixmap. I'm also using a GXxor drawing mode. XForms objects do not
> change color. There is no color flashing.

It's the GXxor mode that's giving you heartburn, I think. Why are you
using GXxor mode rather than GXcopy?

Normally GXxor is used for draw-undraw operations used in "rubber
banding" or lightweight object dragging.

In GXcopy mode the source color is copied into the destination pixel
directly.

In GXxor mode, the source color is exclusive ored with the destination
pixel and that value is then written to the destination pixel. Doing
this twice performs a "draw-undraw" operation:

( A ^ B ) ^ B -> A

I think I'm getting a glimmer of what's happening.

If your background color is black and you're drawing red, then in
TrueColor mode, the operation is

0x000000 ^ 0xff0000 -> 0xff0000

(assuming RGB pixel ordering and a 24 bit pixel -- which is not
exactly right for your application, as I recall, but sufficient for
this example) so you're getting red, as you'd expect.

However, if you're in PseudoColor mode, the GXxor exclusive ors the
look up table *index* for black with the look up table *index* for red
and uses the resulting index as the destination color. Generally,
black will have a LUT index of 1. Assuming that FL_RED has a Colormap
LUT index of, say 0x42, you're going to get

0x01 ^ 0x42 -> 0x43

which is probably not going to be red. Thus your strange colors.

If you want red, you will need to use GXcopy mode or be *very* clever
in fiddling your LUT.

spl
_________________________________________________
To unsubscribe, send the message "unsubscribe" to
xforms-request@bob.usuf2.usuhs.mil or see
http://bob.usuf2.usuhs.mil/mailserv/xforms.html
Xforms Home Page: http://bloch.phys.uwm.edu/xforms
List Archive: http://bob.usuf2.usuhs.mil/mailserv/list-archives/