Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!snorkelwacker.mit.edu!bloom-beacon!LIGHTNING.MCRCIM.MCGILL.EDU!mouse
From: mouse@LIGHTNING.MCRCIM.MCGILL.EDU
Newsgroups: comp.windows.x
Subject: Re: XImages
Message-ID: <9012160732.AA20202@lightning.McRCIM.McGill.EDU>
Date: 16 Dec 90 07:32:25 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 50

>> 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.

Yes, I know.  Clearly which nybble goes in which half of the byte is
specified.  What isn't specified is the order of the bits within a
nybble.  (Of course, the order of the bits within a byte isn't
specified in the >=8 bits/pixel case either, but the reasonable
supposition is much stronger there.)

>> 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:
[...]

> 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.

Yes, this is the problem.

> The fields of XImage struct such as byte_order, bitmap_unit, [...] 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.

This is the problem: where is it promised that one can do this?  As far
as I can tell, it isn't.

It is - I think - promised that XPutImage will deal with it, but if you
bash these fields, nothing guarantees that any of the function handles
installed by XCreateImage will work any longer.  And since nothing
promises anything about the mapping from Xlib calls to the function
handles, the only thing guaranteed to work if you bash the values is
XPutImage.  Even XDestroyImage may break.  (To be sure, it would be a
very twisted implementation, but I don't think it contravenes the spec.)

Basically, the XImage facilities are only partially finished.  They
need to be finished, or else completely redone.  (Presumably the major
thing lacking is human time....)

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu