Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!ncar!ico!attc!marbru From: marbru@attc.UUCP (Martin Brunecky) Newsgroups: comp.windows.x Subject: Re: XImages Message-ID: <936@attc.UUCP> Date: 17 Dec 90 18:00:58 GMT References: <927@attc.UUCP> <9012121928.AA08593@hansen.com> <935@attc.UUCP> Reply-To: marbru@auto-trol.UUCP (Martin Brunecky) Organization: Auto-trol Technology, Denver Lines: 45 >In article <9012121928.AA08593@hansen.com> jim@ncd.COM (Jim Fulton) writes: > > ImageByteOrder specifies whether the Most- or Least-Significant Byte > of each bitmap-unit will be returned first. I replied: Than how do you explain that the Sun's Open Windows (2.0) server and DECwidnows(Ultrix or VMS) servers report oposite ImageByteOrder, but the first *byte* in returned image (accessed as (char*))is my pixel[0,0] for both servers ? (talking 8 bitplane systems on both sides, scanline unit 32 on both sides). Now, when I looked at the MIT code: XImUtil.c, I have found this code: static unsigned long _XGetPixel8 (ximage, x, y) register XImage *ximage; int x; int y; { unsigned char pixel; if ((ximage->format == ZPixmap) && (ximage->bits_per_pixel == 8)) { pixel = ((unsigned char *)ximage->data) [y * ximage->bytes_per_line + x]; if (ximage->depth != 8) ^^^^^^^^^^^^^^^^^^^!!!! pixel &= low_bits_table[ximage->depth]; return pixel; } else { _XInitImageFuncPtrs(ximage); return XGetPixel(ximage, x, y); } } Note this code does NOT pay ANY attention to the ImageByteOrder, yet it will be used whenever the format (the first line) is matched. Is this a deviation from the protocol, or am I interpretting your statement incorrectly ? -- =*= 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