Re: imlib and 24bit color, byte order
- From: raster redhat com
- To: mvachhar vger rutgers edu
- cc: andrew ecsl cs sunysb edu, gnome-list gnome org
- Subject: Re: imlib and 24bit color, byte order
- Date: Sun, 21 Jun 1998 17:16:18 -0400 (EDT)
On 21 Jun, Manish Vachharajani shouted:
-> On Sat, 20 Jun 1998, Andrew V. Shuvalov wrote:
->
-> > Hi,
-> > So we have to detect the Endian'ity
-> > at the start and make two case's in switch for 24 bit mode?
-> >
-> > Andrew
-> >
->
-> Well, its a little worse than that. We have to do nothing to the 32 bit,
-> 16bit, 15bit code if the endianess of the client and server match. We
-> have to write the bytes backwards if the endianess doesn't match.
->
-> The 24bit case isn't so bad, since it only depends on the byte ordering of
-> the 24bit server. The 8bit case doesn't matter.
->
-> The problem is making the 32bit, 16, and 15 bit cases fast when the
-> endianess doesn't match. Then there is also the whole issue of endianess
-> of the client. Is there and autoconf test for this?
->
-> Finally, before I make these changes, I want someone without a Virge card
-> with a server the only accepts 24bpp pixmaps see what happens with the new
-> 24 bit code to see if there is a real problem.
->
-> BTW, do you agree with my analysis? Have you looked at rend.c in ImLib?
all of this can be avoided by simply turning fastrender off when the
endianess and bit order or byte order don't match between client and
server (in that case it uses XPutPixel instead - which does all of this
for us - fastrender is an optimisation to bypass this layer and write
directly - you'll save yourself a lot of work if all you do it leave
the code as it was and add more checks for turning fastrender off).
You'll find the cards that had problems had them dur eot fastrender
being turned on and the system imrc has comments at the fastrender
option stating that its there only as an optimisation and good for you
if it works.
Now you are also disregarding bit order ie what the MSB and LSB are -
this is in addition to byte order in endianess...
-> Manish Vachharajani
-> <mvachhar@vger.rutgers.edu>
->
->
--
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
raster@rasterman.com /\___ /\ ___/||\___ ____/|/\___ raster@redhat.com
Carsten Haitzler | _ //__\\ __||_ __\\ ___|| _ / Red Hat Advanced
218/21 Conner Drive || // __ \\_ \ | | \ _/_|| / Development Labs
Chapel Hill NC 27514 USA ||\\\/ \//__/ |_| /___/||\\ 919 547 0012 ext 282
+1 (919) 929 9443, 801 4392 For pure Enlightenmenthttp://www.rasterman.com/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]