Re: imlib and 24bit color, byte order
- From: Manish Vachharajani <mvachhar vger rutgers edu>
- To: "Andrew V. Shuvalov" <andrew ecsl cs sunysb edu>
- cc: "gnome-list gnome org" <gnome-list gnome org>
- Subject: Re: imlib and 24bit color, byte order
- Date: Sun, 21 Jun 1998 11:41:39 -0400 (EDT)
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?
Manish Vachharajani
<mvachhar@vger.rutgers.edu>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]