Re: 256 color mode and ximtool
Re: 256 color mode and ximtool
- Subject: Re: 256 color mode and ximtool
- From: email@hidden
- Date: Fri, 19 Sep 2008 16:33:55 -0500 (CDT)
On Wed, 17 Sep 2008, Jeremy Huddleston - email@hidden wrote:
If your apps really *need* 256colors, you need to change the output settings
of the server in X11 preferences to 256 colors and restart the server. 8bit
visuals in the TrueColor server are buggy.
I used to run two copies of X11.app (not in Leopard) with one using
TrueColor and the other PseudoColor. (This also allowed me to use xhost
+hostX in one of the X servers since the machine I connected to did not
have sshd.) That worked great in 10.3 and also 10.4 (I think I got a
harmless error message in 10.4). In any case since 256 did not work with
Leopard I found a workaround. I run Xvnc with the -cc 3 -depth 8 options
and run my old program in there. Also it seems I cannot run two X11.apps
anymore so that approach would not work anyway.
Jeremy, it looks like you want to make it so that when you run the Xserver
it will have a number of TrueColor and one PseudoColor visual. Wow that
will be neat if you get that to work. I think I remember that on an old
SGI Indy but that had hardware support for something like this. Is that
what you are going after? If so that should allow us to run our old stuff
inside one X11.app seamlessly. I just want to warn you that I think back
in the 10.2 beta of X11.app or one of the 10.3 versions something like
that was there and it was really broken and then it went away.
One thing is that I see some people are saying some behavior is not right
in programs that used to work say in rc5. The PseudoColor visual when
running the server at 24-bit is really broken right now (and you know
that). That may be the reason that those programs stopped working right. I
could see how some programs would first look for a PseudoColor visual
before a TrueColor one. Imagine you were writing an ANSI terminal emulator
ten years ago for example (before all the font antialiasing stuff and 256
color framebuffers were still common). Switching colormap entries to get
blinking text would be a whole lot easier than redrawing the window all
the time. Those old programs like that still exist. So I bet until the
faked PseudoColor visual in the 24-bit server is working right, it would
be nice to not use that visual unless the server was using depth 8.
Okay now for my experiences with 2.3.1 running in 256 color selected in
the X11.app preferences and my old program which I pounded on a bit
harder. It seemed to work fine for a bit. Then suddenly the background in
my xterm turned purple. This program only uses maybe 8 colors, this color
of purple being one of them. It seems that maybe there is some color
allocation bug where it gives new indexes for colors that are already in
the colormap. (I think this program owns the colormap.) Now what next
happened is I opened a new xterm and it was all fine (no purple). Then I
clicked to focus the first xterm and the background came back to normal
except for a verical stripe at the right side of the xterm. I saw no
affect on the other program (maybe if I had focused it after that I would
have). I minimized the xterm and then clicked on it in the dock to bring
it back and it was again normal (with no purple stripe).
The other oddity is when I turned on blinking in the plots for the 256
only program. They did not blink. I bet the blinking is done my messing
with the color map and that does not seem to work. I bet to get that to
work right you will need to notice that the colormap has changed and
repaint all PseudoColor windows.
So that is the status of what I have learned. Again Jeremy thank you very
much for your hard work, it is getting much closer to having 256 work
again.
mzs
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden