swarm-support
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Color resources on SunOS 4.1.3


From: Sven Thommesen
Subject: Re: Color resources on SunOS 4.1.3
Date: Thu, 18 Jul 1996 15:23:15 -0700

Patrick Maheral wrote:
> 
> Hello,
> 
> This problem has been bothering me for some time now, but I haven't got
> around to solving it yet.  When I run heatbugs demo, I get warnings that
> color 0xXX0000 could not be allocated in the color map (sorry I don't have
> the output message).  This message appears for all of the "reds" in the
> simulation (ie colors 0xXX0000, XX = 00 to FF).  What I end up with is a
> white world with green bugs and no heat (red).
> 
> I realize this is a minor problem, and I just wondered if anyone else has
> come across these warning before.  The machine is a Sun Sparc 5 running
> SunOs 4.1.3 (Rev. B) and OpenWindows 3.0 (X11R4 I believe).
> 
> Any suggestions appreciated.
> 
> Thanks,
> Patrick

Patrick,

this issue has come up before. This is "just the way X works" in default 
mode. Evidently, there's a 256-slot color resource that is shared by 
running programs that do not arrange themselves otherwise. There are 3 
possible avenues to improving the situation:

(1) Swarm can allocate itself a "local" color map, which would make it 
independent of color resources allocated already by hogs like Netscape. 
This solution evidently requires some extra programming to the Swarm 
libraries by Manor or some other knowledgeable X-guru. (It is probably 
not at the very top of Manor's list of Things To Do Right Now.)

(2) I was told that there is a way to tell X in the .Xresources file that 
a given program needs its own local color map, but I haven't had time to 
try it (and the reference is not at hand right this moment). I'll post 
the suggestion here as soon as I locate it.

(3) By default, X runs in 8-bits-per-pixel color mode. I have verified 
that if you run X in 16 or 32 bits-per-pixel mode, the problem (i.e. the 
error messages you cite) goes away. You start x in 16-bit mode by saying
        "startx -- -bpp 16", 
or "startx -- -bpp 32" for truecolor. 
Actually, to see if this is doable in your setup, say 
        "startx -- -bpp 16 > startx.log 2>&1" 
and then look at startx.log after you exit from X. There should be an 
error message if 16bpp was not available.
The capabilities of your graphics card + monitor are set up in the X 
configurator program. On my Linux box, the result ends up in the file
"etc/XF86Config", which is read by X on startup.
(Unfortunately for me, my setup at work does not support 16bpp. :-(
I hope to change that soon ...)

Let us all know if you try #3 and meet with success!

Hope this helps,

--Sven


reply via email to

[Prev in Thread] Current Thread [Next in Thread]