Martin Buchholz <martin(a)xemacs.org> writes:
If you have a recent Sun box, it is likely to come with fancy 24-bit
video cards with names like `ffb' (fast frame buffer).
However, the default visual is only 8-bit. This is a decision by Sun
(mistaken, in my opinion) to improve backward compatibility with old
A system administrator can change the default visual by copying
/usr/dt/config/Xservers to /etc/dt/config and hacking it to add
under-documented flags like -defdepth 24. Few system administrators
will be able to figure this out.
I've checked it with my neighbor's SPARC box (next to my desk :).
When the default visual is 24 bit using Xsun with
"/usr/openwin/bin/Xsun :0 -dev /dev/fb defdepth 24 -nobanner",
both XEmacs 20.4 and 21.0-beta61 came up with TrueColor visual.
Additionally, I've set no X resources at the time.
(fyi: I could not use "-defdepth 24", but "-dev /dev/fb defdepth 24")
An application running in this kind of environment should be able to
recognize that the display is truly 24-bit and create 24-bit windows.
For example, recent netscape's do this properly.
xwininfo on a netscape window:
Visual Class: TrueColor
xwininfo on a xemacs window:
Visual Class: PseudoColor
As a result, display of images in XEmacs is noticeably suboptimal.
How do we fix this?
Had you done `ps -aef | grep Xsun' and found "defdepth" was specified?
It seems like you're running Xsun at 8 bit depth. How about your
"depth of root window:" of "screen #0:"?
Anyway, even if the user doesn't run Xsun at 24 bit depth, the user
can specify the depth using `xemacs -visual TrueColor24 -privatecolormap'.
If you'd like to say that the XEmacs need to choose the best visual
class when the X server had several kind of depths, my opinion is we
just use default visual or do we use XMatchVisualInfo in descent order?
Status xvisualstat = FALSE;
/* 32 bit check */
xvisualstat = XMatchVisualInfo (dpy, screen, 32, DirectColor, &vinfo);
if ( xvisualstat == TRUE )
/* 24 bit check */
/* 16 bit check */
/* 8 bit check */