On Sun, 06 Feb 2000 12:49:17 +0900, Kazuyuki IENAGA said:
In addition to it, could you please give a try X resource
'.emacsVisual' for a workaround?
Emacs.emacsVisual: PseudoColor8
As Valdis mentioned below, device-x.c uses the same way with
Mozilla's. That is if we found useful rich visual class we use it.
Setting the visual by hand will almost certainly work - Netscape
will Get It Right if you order a PseudoColor. I'm *really* curious
exactly why this code fails on the GXT255 and GXT2000 cards - it's
card-specific, as I run the same exact Netscape and AIX versions
at home, but the GT4X card works fine.
I'm thinking there's Something Weird about the implementation of
the 24-bit TrueColor visual on those 2 cards, as even specifying
the visual by number still loses. And it's something subtle -
I run the X server with the TrueColor24 as the *default* visual,
and CDE, Enlightenment, xv, and so on, all work fine. Just
Netscape and Tk/Tcl lose.
I heavily instrumented a copy of Tk/Tcl 8.3b2 last week, and traced
the calls to XAllocColor() and friends. Ran the program in 24-bit
and 8-bit. It *allocated* the same pixel RGB values in both cases,
but *displayed* incorrectly for the 24-bit case. The odd part is
that using 'xmag' to grab a snapshot gets the broken values, so
the pixmap the X server is blitting to the screen is broken.
The next step is to run the program through 'xscope' or similar,
and see if the right value is sent by the Tk/Tcl client, or if it's
getting a busticated value to send to the server.
Can anybody check if the GXT300P has this problem too? If it doesn't,
I'm really tempted to just ask my boss to buy me one ;)
/Valdis