Sorry, but 32 bits per pixel does make sense.
One thing is the number of bits per pixel (i.e.
screen depth), another thing is how many bits
are actually used to represent the colour.
In this case we have 32 bits per pixel, but only
24 bits are actually used for the colour. You may
argue that 8 extra bits for each pixel is just a
waste of video memory. However, the fact that
each pixel requires exactly one 32bit word,
makes it easier and more efficient for programming
the video frame buffer.
Some cards and XServers (including XFree86)
support both 24bit and 32bit modes, that effectively
is the same, but 24bit should be all right (at least
I don't have troubles with it).
I wonder, where xdpyinfo get significant bits in color
specification. It could be a part of Visual structure.
This could give a clue to the actual number of bits
used for colours. Anyway it is better than hardcoding:
"32bits is equivalent to 24bits"
Regards, Michael
> -----Original Message-----
> From: T.C. Zhao [SMTP:tc_zhao@yahoo.com]
> Sent: Wednesday, 22 September 1999 14:54 EST
> To: xforms@bob.usuhs.mil
> Subject: Re: XForms: XForms crashes with LinuxPPC + 32 bpp
>
>
> depth==32 ? This is really interesting. Frankly I think this is
> just plainly wrong. See below.
> so it looks like we have 8bits of red, 8bits of green and
> 8bits of blue, packed GBR. Looks like a depth==24 to me
> (bits per pixel can be whatever the server likes, but depth
> has meaning, i.e.,if depth is k, I would expect I can get 2^k-1
> colors).
>
> In any case, xforms tried 1<<depth-1, and got a minus 1, which
> was subsequently used to communicate with the server and really
> upsets it. I'll try add some workaround.
>
>
_________________________________________________
To unsubscribe, send the message "unsubscribe" to
xforms-request@bob.usuhs.mil or see
http://bob.usuhs.mil/mailserv/xforms.html
XForms Home Page: http://bragg.phys.uwm.edu/xforms
List Archive: http://bob.usuhs.mil/mailserv/list-archives/