Subject: Re: links-gui on cgsix
To: None <port-sparc@NetBSD.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: port-sparc
Date: 06/24/2006 22:41:15
>> Since a cgsix cannot support multiple colourmaps on the screen at
>> once, [...technicolour colourmap flashing...]
> That's fine, in fact that's what happens on my IBM T30 when I run X
> in 8-bit color, so the 8-bit color on my cgsix is somehow different
> than say an ATI Radeon.

Really?  How?  Your description sounded exactly like colourmap
contention to me.  How does the behaviour on your cgsix differ from
that on your Radeon?

> I wonder if it's possible that links-gui is that it's generating a
> palette that's not appropriate for an 8-bit Sun card.

I don't think that's possible.  The cgsix can handle any colourmap that
can be described with 8bit in and 3x8bit out.

> Here's an excerpt from x.c:

>     250         case 8:
>     251         for (a=0;a<256;a++)
>     252         {
>     253             color.red=tbl1[(a>>5)&7];
>     254             color.green=tbl1[(a>>2)&7];
>     255             color.blue=tbl0[a&3];
>     256             color.pixel=a;
>     257             color.flags=DoRed|DoGreen|DoBlue;
>     258             XStoreColor(x_display,x_colormap,&color);
>     259         }
>     260         break;

Okay, it's using a fairly boring 3,3,2 pseudo-TrueColor scheme.  (It's
also doing it badly; it really should be doing one XStoreColors() call
rather than 256 XStoreColor() calls.)

> The other theory I have is that there is function being used that has
> platform-specific behavior such as WhitePixel and BlackPixel:

> According to the Xlib Programming Manual, these are not always equal
> to #000000 and #ffffff.

Right.  They are neither always pure white and pure black nor are they
always any particular pixel values.

It's less likely to be a result of links using WhitePixel and
BlackPixel than it is to be a result of other applications doing so
(or, in some sense equivalently, looking up the values they want in the
default colourmap).

Your default visual is StaticGray, which has a predefined colourmap
containing implementation-specific grayscale values.  It's quite
possible that, for example, the server on your Sun uses pixel value 0
for white and 1 for black, with the rest containing other greyscale
values, while on the Radeon, the server uses 0 for black and 255 for
white.  This would make a difference because a black-and-white
application, while looking identical when using the correct colourmap,
will look very different using links's pseudo-TrueColor colourmap.

> I couldn't find a way to force anything.  I don't yet understand why
> a an application would use anything but the DefaultColormap and
> DefaultVisual to begin with.

Because it wants to be able to display colour and the default visual
doesn't support it, would be my guess.  Since there are colour visuals
available, it uses one of them.  (Why it picks a PseudoColor visual
when there's a TrueColor visual available and it appears to to want
TrueColor, that I find baffling.  The use of XStoreColor instead of
XStoreColors leads me to suspect that the author may have had a shaky
understanding of Xlib, which likely would include a weak grasp of the
Visual model.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B