| Re: Graphics problem on Sun Ultra2 workstation [message #35851] |
Thu, 31 July 2003 10:39  |
Karl Schultz
Messages: 341
Registered: October 1999
|
Senior Member |
|
|
"Timm Weitkamp" <timm.weitkamp@nowhere.edu> wrote in message
news:Pine.LNX.4.44.0307311024590.3502-100000@localhost.local domain...
> Alex and Jim,
>
> I have little knowledge about the hardware internals of computer graphics,
> but I have seen the phenomenon described by Alex lots of times on
> different kinds workstations (HP, Sun...). It occurs not only with IDL.
>
> I am pretty sure that this is simply the way that their 8-bit visuals deal
> with any application's attempt to allocate a larger number of colors than
> is left free by the other applications (including the window manager).
> In this case, the application gets a "private colormap", and every time
> the focus is put in the application's window, the entire screen switches
> to this colormap, inevitably messing up the rest of the screen. In other
> words: it's a feature, not a bug.
Agreed. This was just the way X chose to deal with the color allocation
problem. Windows, by contrast, does dynamic palette remapping and also
reserves some desktop colors so that the vital parts of the desktop like the
window frames stay the same color.
> I'd be surprised if it had anything to do with the refreshing rate.
Agreed.
> Alex, your Sun probably has Netscape installed, right? Try start it by
> typing "netscape -install". This forces Netscape to install a private
> colormap, and the Netscape window should then exhibit the same behavior as
> the IDL graphics window. The advantage is of course that Netscape or IDL
> can use the full 8-bit range of colors for themselves if they install a
> private colormap.
This keeps Netscape from using up colors in the screen's default colormap,
which will delay exhausting the free colors in this shared colormap. The
downside is that when Netscape gets colormap focus, Netscape's colormap will
get installed (loaded into the hardware's color table) and the other
clients' colors will be false. Not a big problem, as long as you are aware
of it.
> A particularly smart program in this respect is Xfig,
> which switches to a private colormap during runtime as soon as the user
> wants to use colors that are not available in the public colormap.
IDL's capabilities in this area are explained in the IDL documentation for
the X device. The docs also explain the shared and private colormap issues
pretty well. In general, IDL's WINDOW command gives the user a bit of
control over how colors are allocated. Specifically, if you try to create a
window with a lot of colors (COLORS keyword), IDL will use a private
colormap if the colors cannot be allocated from the shared colormap.
> Can it be helped? I don't know. I used to live with it. Also, it usually
> didn't occur if I avoided having other color-intensive applications
> running when starting IDL.
One other culprit is the desktop itself. If you are running CDE, try
adjusting the color usage settings in the desktop preferences. You can take
it all the way down to just black and white, if you want. Sometimes,
reducing the colors on the desktop can make a huge difference.
Some of our Sun machines have a client called xcmap that displays 256-color
PseudoColor colormap usage. It can help you see how many colors are being
used. It is sort of fun to watch as you run clients that fool around with
colors a lot.
Karl
>
> Timm
>
>
> Timm Weitkamp <http://people.web.psi.ch/weitkamp>
>
>
> On 30.07.03 at 15:04 -0700, Jim Brauher wrote:
>
>> Alex,
>>
>> I've seen this problem before. You might want to examine your
>> visual depth, resolution, and cycle rate. Try the following:
>>
>> % xdpyinfo
>>
>> which will give you a list of the various visuals available on your
>> machine as well as the current one. I also assume you want to use 24
>> bit color depth.
>>
>> Now try the m64config command under Solaris, but first read the
>> manpage because this is a tricky command. The color flash is likely
>> due to the number of cycles that your monitor is refreshing at. Look
>> for a higher one (75 or 76 cycles).
>>
>> After that, use the m64config to change your color depth and
>> resolution.
>>
>> % m64config -depth 24
>> % m64config -res 1280x1024x76 (or some resolution that is available to
>> you)
>>
>> Now log out of your X session and log back in. Note that this may
>> affect some of your other applications if you were running in 8-bit
>> Pseudocolor mode before.
>>
>> Hope this helps.
>>
>> Jim
>>
>>
>> Wonko@wonkology.org (Alex Schuster) wrote in message
news:<8qsf3D1Pd8B@wonkology.org>...
>>> Hi there!
>>>
>>> I've been away from this group for some time.. too many thing to do,
>>> too less time.
>>>
>>> I am having trouble with our two new (well, some years ago they were
>>> new) SUN Ultra2 workstations and IDL (5.2). Whan I start IDL, and
>>> enter the WINDOW command, a white window appears. If I move the mouse
>>> cursor into the window, I get the correct black color, but my desktop
>>> colors switch, too.
>>>
>>> I know this from other SUNs, but it never was a real problem, as
>>> switching to pseudo color mode (DEVICE, PSEUDO=8) or setting DEVICE,
>>> DECOMPOSED=0 solved it.
>>>
>>> This does not work with the new SUNs. All I can do is a device,
>>> true_color, this prevents the color flickering. But I have tons of
>>> programs using pseudo color mode that I don't want to change to true-
>>> color mode.
>>>
>>> Any ideas? I'm sorry that I don't know much about the graphics card,
>>> only that it's a Creator model, that's what the logo on the front
>>> panel says. We have other SUNs (Ultra-1), with Creator 3d cards, and
>>> they work well. I don't think there is an easy solution, but I thought
>>> I'd give the group here a try.
>>>
>>> TIA,
>>>
>>> Alex
>>
>
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
