| Re: LINUX Device Question [message #43208] |
Thu, 24 March 2005 15:17 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Michael Wallace writes:
> We say the same thing about you as well..."Isn't it amazing what they
> are willing to put up with even though they are shelling out big $$$ to
> Microsoft?" ;-)
Maybe this is all there is. Wouldn't that be frightening!? :-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
|
|
|
|
| Re: LINUX Device Question [message #43209 is a reply to message #43208] |
Thu, 24 March 2005 15:07  |
Michael Wallace
Messages: 409
Registered: December 2003
|
Senior Member |
|
|
> Isn't it amazing what we are willing to put up with
> just to have a free OS. :-)
We say the same thing about you as well..."Isn't it amazing what they
are willing to put up with even though they are shelling out big $$$ to
Microsoft?" ;-)
|
|
|
|
| Re: LINUX Device Question [message #43211 is a reply to message #43209] |
Thu, 24 March 2005 14:57 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
wmc@bas.ac.uk writes:
> Errr... maybe this is vaguely relevant to my problem: idl colours under
> linux; wanting to use 8-bit to get colour tables; set display appropriately.
> Then under gnome/kde, colour tables don't work properly: I can use xloadct
> to load new tables, but the tables don't show up in normal plot windows,
> *unless* you hold the mouse over the graphics portion of a widget, whereupon
> it works OK! OTOH, under windowmaker, all is fine (except for the inconveniences
> of using windowmaker of course...).
Isn't it amazing what we are willing to put up with
just to have a free OS. :-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
|
|
|
|
| Re: LINUX Device Question [message #43212 is a reply to message #43211] |
Thu, 24 March 2005 14:50 |
wmconnolley
Messages: 106
Registered: November 2000
|
Senior Member |
|
|
Karl Schultz <k____schultz@rsinc.com> wrote:
> 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".
Errr... maybe this is vaguely relevant to my problem: idl colours under
linux; wanting to use 8-bit to get colour tables; set display appropriately.
Then under gnome/kde, colour tables don't work properly: I can use xloadct
to load new tables, but the tables don't show up in normal plot windows,
*unless* you hold the mouse over the graphics portion of a widget, whereupon
it works OK! OTOH, under windowmaker, all is fine (except for the inconveniences
of using windowmaker of course...).
-W.
--
William M Connolley | wmc@bas.ac.uk | http://www.antarctica.ac.uk/met/wmc/
Climate Modeller, British Antarctic Survey | Disclaimer: I speak for myself
I'm a .signature virus! copy me into your .signature file & help me spread!
|
|
|
|
| Re: LINUX Device Question [message #43214 is a reply to message #43212] |
Thu, 24 March 2005 14:39 |
Michael Wallace
Messages: 409
Registered: December 2003
|
Senior Member |
|
|
FWIW, here's the situation I ran into and how I worked around it.
The Setup:
Fedora Core 1
Gnome Desktop
IDL 6.1.1 (and previous versions)
The Problem:
Go into IDL and run XLOADCT. No matter which color table you select,
the same greyscale table is shown. However, if you move your mouse over
the color bar in the XLOADCT widget, the colors on your entire desktop
flash. The colorbar now looks like what you expect but all the other
colors on your screen flash as well. The flashed colors remain until
you move the mouse outside the color bar. The colorbar goes back to
greyscale and the desktop colors go back to normal.
I'm only mentioning XLOADCT in the example because it's the easiest way
I've found to reproduce the error.
The Solution:
The only solution I could find was the solution given the old UNIX color
flashing problem. While this is not the same problem exactly, the
solution works here as well. The techtip covering flashing colors on
UNIX is here: http://www.rsinc.com/services/techtip.asp?ttid=1688.
In particular, I set
Idl.gr_visual: TrueColor
Idl.gr_depth: 24
With this, all behavior is back to normal. Color tables show up and
there's no weird XLOADCT behavior.
-Mike
|
|
|
|
| Re: LINUX Device Question [message #43217 is a reply to message #43214] |
Thu, 24 March 2005 13:24 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Karl Schultz writes:
> 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.
You should be getting a call real soon now. :-)
This "gray" problem is *exactly* what we seem to be experiencing!
Thanks, Karl.
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
|
|
|
|
| Re: LINUX Device Question [message #43220 is a reply to message #43217] |
Thu, 24 March 2005 11:36 |
mmiller3
Messages: 81
Registered: January 2002
|
Member |
|
|
>>>> > "David" == David Fanning <davidf@dfanning.com> writes:
> Folks, I'm helping someone with an extremely weird color
> table problem.
> Could someone with a 24-bit color LINUX machine send me the
> results of a HELP, /DEVICE command after starting IDL up
> with these commands:
> DEVICE, TRUE_COLOR=24 DEVICE, DECOMPOSED=0
Here you are:
lumen:miller\>unset IDL_STARTUP
lumen:miller\>idl
IDL Version 6.0 (linux x86 m32). (c) 2003, Research Systems, Inc.
Installation number: 8285.
Licensed for use by: Indiana University Radiology
IDL>
IDL> DEVICE, TRUE_COLOR=24
IDL> DEVICE, DECOMPOSED=0
IDL> HELP, /DEVICE
Available Graphics Devices: CGM HP LJ NULL PCL PRINTER PS REGIS TEK X Z
Current graphics device: X
Server: X11.0, The XFree86 Project, Inc, Release 40300001
Display Depth, Size: 24 bits, (1600,1200)
Visual Class: TrueColor (4)
Bits Per RGB: 8 (8/8/8)
Physical Color Map Entries (Emulated / Actual): 256 / 256
Colormap: Private, 16777216 colors. Translation table: Enabled
Graphics pixels: Combined, Dither Method: Ordered
Write Mask: 16777215 (decimal) ffffff (hex)
Graphics Function: 3 (copy)
Current Font: <default>, Current TrueType Font: <default>
Default Backing Store: Req from Server.
IDL>
IDL> print, !version
{ x86 linux unix linux 6.0 Jun 27 2003 32 64}
|
|
|
|
| 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
|
|
|
|
| Re: LINUX Device Question [message #43222 is a reply to message #43220] |
Thu, 24 March 2005 10:55 |
Michael Wallace
Messages: 409
Registered: December 2003
|
Senior Member |
|
|
> 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.
> Could someone with a 24-bit color LINUX machine send me
> the results of a HELP, /DEVICE command after starting
> IDL up with these commands:
>
> DEVICE, TRUE_COLOR=24
> DEVICE, DECOMPOSED=0
IDL> device, true_color=24
IDL> device, decomposed=0
IDL> help, /device
Available Graphics Devices: CGM HP LJ NULL PCL PRINTER PS REGIS TEK X Z
Current graphics device: X
Server: X11.0, The XFree86 Project, Inc, Release 40300000
Display Depth, Size: 24 bits, (1024,768)
Visual Class: TrueColor (4)
Bits Per RGB: 8 (8/8/8)
Physical Color Map Entries (Emulated / Actual): 256 / 256
Colormap: Private, 16777216 colors. Translation table: Enabled
Graphics pixels: Combined, Dither Method: Ordered
Write Mask: 16777215 (decimal) ffffff (hex)
Graphics Function: 3 (copy)
Current Font: <default>, Current TrueType Font: <default>
Default Backing Store: Req from Server.
-Mike
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
