Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!rex!samsung!noose.ecn.purdue.edu!delta.ecn.purdue.edu!luj From: luj@delta.ecn.purdue.edu (Jun Lu) Newsgroups: comp.windows.x Subject: Re: XImages Message-ID: <1990Dec12.191533.14361@noose.ecn.purdue.edu> Date: 12 Dec 90 19:15:33 GMT References: <9012101728.AA23279@test4> <927@attc.UUCP> Sender: news@noose.ecn.purdue.edu (USENET news) Organization: Purdue University School of Aeronautics and Astronautics Lines: 33 In article <927@attc.UUCP> marbru@auto-trol.com (Martin Brunecky) writes: > > My *observation* is that IF I access image data as BYTES on either > SPARC or DECstation, I must assume MSBfirst no matter what the XImage > structure says. Not true(at least for Sparcs). In the case that a image is stored as bytes, byte_ordering is not important. You can always specifiey the byte_order with the macro ImageBteOrder(dpy) -- becasue for byte images, byte_order does not really matter.(Of course, you can arbitrarily specify the byte_order as LSBFirst if you insist). > IF I access image data as scan-units (32 bits in this case), I must > honor the "image byte order". Agree. > What does NOT make sense to me, is that the BYTE order in 32 bit unit > is a CLIENT machine feature, not the SERVER machine. Depends on how you get your images. In the case that the client read the image from a disk, the image byte_order should be specified according to how the image is actually stored in the client memory and this byte_ordeing has nothing do with whether the client is big_endian or little_endian. In the case the client gets its image by the request XGetImage, the XImage struct should never be modified and the client should access the image according the the byte_order/bit_order returned. -- -- 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 --