Re: imlib and 24bit color, byte order

[raster redhat com]

On 19 Jun, Manish Vachharajani shouted:
->  
->  This is a little of topic, but, I am trying to make ImLib work 
->  with servers that only support pixmaps with 24 bits per pixel.
->  With my S3 Virge/VX and the XF86_SVGA server the byte ordering seems to be
->  backwards, basically, when masks are as follows:
->  
->  r_mask = 0xff0000;
->  g_mask = 0x00ff00;
->  b_mask = 0x0000ff;
->  
->  The colors come out as if the byte order were bgr.

yest again.. turn fastrender off.. :) its an optimisation to bypass a
layer of byte endianess conversion iuf the ednianess and order is
exactly as expected and doesnt have to be twiddled much.

->  I think this is because the server wants LSBFirst byte order, but the 24
->  bit render code puts it in MSBFirst. Looking
->  at the imlib render code, I think that there will be portability problems
->  with all color depths when the client is Little endian and the server
->  wants MSBFirst byte order, does anyone disagree?

i have code in misc.c that turns off fastrender if the client and server
differ in endianess.. adding mroe checks there might be the way to go..

->  
->  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/