| Re: problem loading color palette [message #49476 is a reply to message #49404] |
Tue, 25 July 2006 07:55  |
Karl Schultz
Messages: 341
Registered: October 1999
|
Senior Member |
|
|
On Tue, 25 Jul 2006 03:57:47 -0700, aetherlux wrote:
> Karl Schultz wrote:
>> On Mon, 24 Jul 2006 09:10:36 -0700, aetherlux wrote:
>>
>>> Hi everybody, I use IDL 6.0 with Debian GNU/Linux. Today after trying
>>> to load a color palette to draw several maps, I have noticed that the
>>> palette is not loaded.
>>> I use:
>>> device, decomposed=0
>>> xloadct (and then I choose the palette or loadct, 41 -- the number of
>>> the palette)
>>>
>>> It happens with all the palettes.
>>> I guess that it is related with the X server. Perhaps it is a
>>> consecuence of a recent update from Debian Sarge to Etch, which has
>>> changed my Xserver (in Sarge it was XFree86 and now in Etch is Xorg).
>>>
>>> Does anybody know a solution to force IDL to load the palettes?
>>
>> It really may be more of a function of your desktop software, especially
>> the window manager.
>>
>> Term: ICCCM - Inter-client communications convention manual
>>
>> IDL uses the ICCCM-compliant method of setting the colormap ID in the
>> top-level window. A ICCCM-compliant window manager is supposed to notice
>> this and make that colormap active (this is known as "installing" a
>> colormap) when the window receives colormap focus. The colormap focus
>> policy is often the same as pointer focus policy, but it also may be
>> different.
>>
>> First, try just clicking or pointing at the window, to set focus on that
>> window. If that does not work, investigate your window manager's colormap
>> focus capabilities and see if there is an option that you can adjust to
>> make it work.
>>
>> A lot of newer desktops and window managers steadfastly refuse to install
>> a different colormap on the server because it causes all the GUI elements
>> on the desktop to appear with "false colors". There is some debate over
>> the ICCCM and some desktops sort of "ignore" some parts of it.
>>
>> As a last resort, try the undocumented feature:
>>
>> DEVICE, /INSTALL_COLORMAP
>>
>> This makes IDL use the non-ICCCM-compliant method of installing the
>> colormap itself whenever the window gets focus.
>>
>> You might also try using a TrueColor visual (DEVICE, TRUE_COLOR=24). But
>> I think this causes IDL to translate the colors through the palette on
>> the client side, which is not as fast.
>>
>> Hope this helps,
>> Karl
>
> I've tried it. I had seen about this in the ITT/RSINC web page. I am
> using IDL in two different laptops, the first with Ubuntu and Gnome and
> the other with Debian and Icewm. In the Debian/icewm laptop when I run
> the program first the new window appears almost out of the screen, to
> the left of the screen.
I don't know what might be causing this. I have a laptop with Ubuntu
installed - maybe I'll see if I have the same problem.
Are you using a virtual desktop that is larger than the physical screen?
You also might submit this issue to ITTVIS Technical Support with all the
supporting information. That way, you can be sure it will be
investigated.
> Although I have tried to choose my palette, it has not been loaded and
> the colors are from the default IDL palette. If I move the mouse pointer
> to the window with the map (almost out of the screen) then the map
> colors change and it is showed with the right colors. By the way, the
> complete icewm desktop environment changes to awful and strange colors.
That is exactly the expected behavior. This is all about the colormap
installation process that I tried to explain above. You see, all but very
expensive graphics systems have only one color table in its hardware. When
an X client, like IDL, wants its own color table, it must share this
hardware resource with other clients, including all the desktop crud. So,
the window manager adjusts the contents of the hardware color table
depending on which client has the focus. If you don't buy my explanation,
then read some material about X Windows. These issues are fairly well
known and understood.
Again, this "colormap flashing" issue is regarded as pretty distasteful in
the Linux community. One approach to avoiding it is using the TrueColor
visual. More recent versions of IDL now try to use a TrueColor visual
before DirectColor by default for this very reason. You can explicitly
request this behavior by using "DEVICE, TRUE_COLOR=24" before issuing any
graphics commands. I think you'll be much happier if you do this.
> I have a bigger problem, now the image is showed with right colors, but
> the my output file with this map in yet saved with the default colors.
Sorry, I don't know what you mean by "output file". You'll need to say
how you created it.
Karl
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
