From xemacs-m  Thu Sep 18 23:18:09 1997
Received: from turnbull.sk.tsukuba.ac.jp (turnbull.sk.tsukuba.ac.jp [130.158.99.4])
	by xemacs.org (8.8.5/8.8.5) with SMTP id XAA20829
	for <xemacs-beta@xemacs.org>; Thu, 18 Sep 1997 23:18:03 -0500 (CDT)
Received: from turnbull.sk.tsukuba.ac.jp(really [127.0.0.1]) by turnbull.sk.tsukuba.ac.jp
	via smtpd with esmtp
	id <m0xBuYd-00000wC@turnbull.sk.tsukuba.ac.jp>
	for <xemacs-beta@xemacs.org>; Fri, 19 Sep 1997 13:20:43 +0900 (JST)
	(Smail-3.2 1996-Jul-4 #3 built 1997-Jun-24)
Message-Id: <m0xBuYd-00000wC@turnbull.sk.tsukuba.ac.jp>
To: "XEmacs Beta" <xemacs-beta@xemacs.org>
Subject: Re: "Bern" colormap interactions 
In-reply-to: Your message of "18 Sep 1997 19:22:51 MST."
             <m2iuvykpok.fsf@altair.xemacs.org> 
Date: Fri, 19 Sep 1997 13:20:42 +0900
From: "Stephen J. Turnbull" <turnbull@turnbull.sk.tsukuba.ac.jp>

>>>>> "sb" == SL Baur <steve@xemacs.org> writes:

    sb> Karl M Hegbloom <karlheg@inetarena.com> writes:
    >>>>>>> "Stephen" == Stephen J Turnbull
    >>>>>>> <turnbull@turnbull.sk.tsukuba.ac.jp> writes:
    Stephen> Apparent bad colormap interactions---not XEmacs's fault I
    Stephen> believe, but advice welcome.

    sb> (Were the screen shots of that program limited to 8 bit color?
    sb> Somehow I was expecting something more ...)

Weren't no screen shots.  Sorry about that.  My mail machine is not
the same machine I do XEmacs on yet, I was too lazy to deal with it.

But yes, Karl guessed right, it was 8bit color:

    >> See if your video card will support 16 bit color.  Try starting
    >> the server with `-bpp 16'.

This fixes it for the moment.  However, the visual changed from
PseudoColor under 8bpp to TrueColor under 16bpp, which I would guess
stops the problem cold (I forget which of TrueColor and DirectColor
has the fixed palette though).

XCthugha was _already gone_ (windows closed, CD stopped, even the
xterm I'd started it from had been closed) when I fired up the new
XEmacs and the lightgrey-on-white color glitch happened (that's why I
noticed it; otherwise I would have assumed it was a bug in XCthugha
only, not an interaction with XEmacs).  (I guess showing that is a
good enough reason to include a screen shot; mea culpa.)

When XEmacs started up, and the "autoloading..." messages started
flying by, suddenly the color of BlackPixel changed.  Eeek.  (And I
can't take MPEGs to tell you which package was autoloading at the
time.)  Any newly loaded xterms with default foreground had the same
color glitch, but newly loaded "xterm -fg black" had nice readable
black-on-white text.

Having dug out an O'Reilly X windows vol. 2, that looks like either
fvwm 2.0.45beta or the Xfree86 3.3 server screwed up to me; WhitePixel
and BlackPixel should be readonly (they're guaranteed to be
contrasting by Xlib).  (Other colors also changed, but I don't see
anything that says that's illegal, although it's impolite; I guess
fvwm just trusts clients too much?)

My assumption is that XEmacs is a good citizen in this respect, of
course.  My initial reaction was "something's weird with XEmacs", but
now that I've studied a bit I think it's presumably just that XEmacs
uses quite a few colors in its usual configuration; anything that uses 
lots of colors will trigger the same problem.  Right?

    >> If it doesn't, upgrade it.  You can get an inexpensive PCI
    >> S3Trio64+ for under $60 I bet.  That's what I use, and it's
    >> working just fine.

    sb> Are we actually in a position to be able to recommend this?
    sb> It sure would be nice.

Not on this side of the puddle (Japan); there are lots and lots of
486s and 8bits-at-usable-resolution video cards still in use around
me.  And my department at my university has a widely envied equipment
budget.

OTOH, for this particular problem, on a 133MHz Gateway P5 running
XCthugha puts the load average up to 1.5; I don't think people who
can't afford decent video cards will be running this program much.
And NEC and Toshiba and IBM run about 25 commercial spots each pushing
"multimedia network computing" between 6 and 12pm every night ... the
basic acceptable level of hardware will improve fast, here in Japan.

-- 
                            Stephen J. Turnbull
Institute of Policy and Planning Sciences                    Yaseppochi-Gumi
University of Tsukuba                      http://turnbull.sk.tsukuba.ac.jp/
Tel: +81 (298) 53-5091;  Fax: 55-3849              turnbull@sk.tsukuba.ac.jp

