Path: utzoo!attcan!uunet!cs.utexas.edu!samsung!noose.ecn.purdue.edu!gus16.ecn.purdue.edu!luj
From: luj@gus16.ecn.purdue.edu (Jun Lu)
Newsgroups: comp.windows.x
Subject: Re: XImages
Message-ID: <1990Dec12.052259.7256@noose.ecn.purdue.edu>
Date: 12 Dec 90 05:22:59 GMT
References: <9012091630.AA14377@Larry.McRCIM.McGill.EDU>
Sender: news@noose.ecn.purdue.edu (USENET news)
Organization: Purdue University School of Aeronautics and Astronautics
Lines: 54

In article <9012091630.AA14377@Larry.McRCIM.McGill.EDU> mouse@LARRY.MCRCIM.MCGILL.EDU writes:
>
>             If bits-per-pixel is less than
>8, then it must be a factor of 8, so each byte holds an integral number
>of pixels; the pixels are then packed into bytes as specified by the
>image-byte-order.  (If the bits-per-pixel equals 8, each pixel is one
>byte and there is no problem.)  It is not clearly specified how a
>pixel's bits are arranged when multiple pixels are packed into a byte,
>but I would assume (and it is an assumption) that each pixel's bits are
>ordered MSB to LSB in the same direction as the byte's bits.

The protocol doc page 10 states: when the bits_per_pixel is 4, the order of
nibbles in the byte is the same as the image byte_order.

>
>An XImage contains six values which are presumably related to some of
>the values I talked about above.  The relevant members of the XImage
>structure, from the Xlib document, are:
>
>     int format;              /* XYBitmap, XYPixmap, ZPixmap */
>     int byte_order;          /* data byte order, LSBFirst, MSBFirst */
>     int bitmap_unit;         /* quant. of scanline 8, 16, 32 */
>     int bitmap_bit_order;    /* LSBFirst, MSBFirst */
>     int bitmap_pad;          /* 8, 16, 32 either XY or ZPixmap */
>     int depth;               /* depth of image */
>     int bits_per_pixel;      /* bits per pixel (ZPixmap) */
>
>There are also
>
>     int xoffset;             /* number of pixels offset in X direction */
>     int bytes_per_line;      /* accelerator to next scanline */
>
>but they are not essential to the discussion here.  They are relevant
>only when you want to manipulate a sub-image of an image you already
>have in memory (or, for bytes_per_line, as an accelerator when stepping
>through scanlines).

Basically, two things need to be distinguished: image format as required by
the server characterstics versus the image acutally stored in the client cpu
memory.  The fields of XImage struct such as byte_order, bitmap_unit,
bitmap_bit_order, bitmap_pad, (depth), bits_per_pixel, (bytes_per_line) 
as returned by XCreateImage are the characteristics of the server, and
they may not be the same as how the image is actually stored in the client
cpu.  Therefore,  one should fill those fields according to how image is
actually stored. In case that the client-side image is in a format different
from that required/supported by the server, XPutImage will do necessary
conversions for client before it acutally send the image to the server.


--
-- Jun Lu                          Internet:luj@ecn.purdue.edu          --
-- Aeronautics & Astronautics      Bitnet:  luj%ecn.purdue.edu@purccvm  --
-- Purdue University		   UUCP:    pur-ee!luj                  -- 
-- W. Lafayette, IN 47907          Phone:317-494-9410  Fax:317-494-0307 --