| Re: LINUX Device Question [message #43221 is a reply to message #43220] |
Thu, 24 March 2005 11:51   |
Karl Schultz
Messages: 341
Registered: October 1999
|
Senior Member |
|
|
On Thu, 24 Mar 2005 12:55:09 -0600, Michael Wallace wrote:
>> I'm helping someone with an extremely weird color table
>> problem.
>
> I had a really strange color table problem on Linux. No matter what I
> did, I would only see grayscale colors. In XLOADCT, when I'd mouseover
> the colorbar all colors on the screen would flash. As soon as I moused
> out the colors outside of the IDL widget would go back to normal and the
> colors in the IDL widget would go back to gray. If this is what you
> mean by "weird color table problem," I can tell you exactly what to do
> to fix it.
I don't know how related this is to either problem, but:
Even if you are on a 24-bit X server, you can experience the
color-flashing problem that was common on 8-bit servers if you use the
DirectColor visual. When you run XLOADCT and pick a color table other
than the default, IDL is going to make an X private colormap for the
window and load it with the color table you chose. Since most X servers
and hardware are only capable of scanning the frame buffer out to the
display through a single color table, if the color table that is currently
loaded is for one client (IDL in this case), then the other clients will
"flash" and display false colors.
This is exactly the same problem that confused people on 8 bit PseudoColor
displays for so long.
Many Linux X servers provide both the TrueColor and DirectColor visuals
with either 16 or 24 bit depths, as you specify in your X config file.
IDL uses a selection algorithm that picks DirectColor over TrueColor,
unless you say otherwise. So, many people work around this problem by
using DEVICE, TRUE=24 or setting their X defaults to force the usage of a
TrueColor visual. You can't get color flashing with TrueColor, but you
can't do rapid color table animations either. An IDL color table change
requires replacing the pixels in the frame buffer, which is slower than
changing the color table. I don't know how big a deal that is for people.
All that being said, there are some serious bugs with "colormap
installation" in some of the newer Linux desktop environments. "Colormap
installation" is supposed to be handled by the window manager. If a
window has a private colormap, the window manager is supposed to make it
the active colormap when the window has focus. This is what causes the
flashing, but is necessary to ensure that the window with the focus has
the correct colors. The bug is that the window manager isn't always doing
the colormap installation, and that leaves your IDL graphics window
"grey", "no matter what you do". I've seen the problem in KDE with kwin
and also in gnome. See/Google the ICCCM for more details on the "rules".
I'm actually surprised to see the XLOADCT makes the colormap installation
happen, and I'll have to look into that. (I was able to do it on my linux
box too.) I can't get the colormap to install (flash the screen) when
doing other things in IDL. I'm sort of in the middle of looking at this
right now anyway, so any additional information would be useful.
The KDE desktop and apps all tend to use the TrueColor visual by default,
so this problem isn't a big deal to them.
Karl
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
