Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!ncar!ico!attc!marbru From: marbru@attc.UUCP (Martin Brunecky) Newsgroups: comp.windows.x Subject: Re: XImages Message-ID: <927@attc.UUCP> Date: 11 Dec 90 16:58:54 GMT References: <9012101728.AA23279@test4> Reply-To: marbru@auto-trol.com (Martin Brunecky) Organization: Auto-trol Technology, Denver Lines: 36 In article <9012101728.AA23279@test4> jimf@SABER.COM writes: > >Yea, the XImage stuff is not well designed or documented. It's highly >portable, though, to allocate an XImage and smash the attributes you >want into the structure. Xlib (at least all of them I've used) will >convert to server-natural format for you. This is highly convenient >because all you have to do is describe what your image looks like and >send it off. > Well, the XImage stuff documentation deserves a LOT. So far, I'v seen 3 guys struggling with it, and each comming back with completely different understanding of the subject. And even after working with all three guys and having the code which seems to correctly receive, process and put images to a variaty of servers, I still do NOT get the mening of "image byte order". For image bit order, MSBfirst/LSBfirst are crystal clear. But when it comes to byte order ... 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. IF I access image data as scan-units (32 bits in this case), I must honor the "image byte order". 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. To add to the confusion, the protocol request (73),GetImage specifies the image data as LISTofBYTES. Any explanations ? -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky {...}sunpeaks!auto-trol!marbru (303) 252-2499 (sometimes also: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404