Path: utzoo!attcan!uunet!ncrlnk!ncrcae!hubcap!gatech!bloom-beacon!GODOT.RADONC.UNC.EDU!sherouse
From: sherouse@GODOT.RADONC.UNC.EDU (George W. Sherouse)
Newsgroups: comp.windows.x
Subject: Re: XPutPixel
Message-ID: <8811151509.AA07399@godot.radonc.unc.edu>
Date: 15 Nov 88 14:09:26 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 32

> From: rws@expo.lcs.mit.edu (Bob Scheifler)
> Subject: Re: XPutPixel 
> Date: Tue, 15 Nov 88 09:16:32 EST
> 
>     Why not make XImage.data (unsigned long *) and be
>     done with it?
> 
> Umm, if you think PutPixel is slow, imagine the server having to
> accept a depth 1 image (bit per pixel) in your proposed format,
> and have to compact it down to a bitmap format acceptable for
> blitting onto the screen.

I'm not sure I understand your point.  Clearly *somebody* has to
eventually make the image match the hardware.  You seem to suggest it
would be less efficient to have the server (which may have access to
some specialized image munging hardware, and is in a much better
position to make other hardware-specific optimizations) do this than
to have clients do it.  Aside from the increased wire traffic I don't
see how that can be.

If your position is that always sending images as (unsigned long)
*REQUIRES* XPutPixel-like handling of every pixel on the server side -
handling which cannot be sidestepped - then I do see some rational for
retaining the current model.  But, again, it is not clear that
building conversions into the server *necessarily* removes a client's
option to make non-portable assumptions in the name of speed.

BTW, forgive my bias toward "thick" images.  I confess to not
having considered 1-bit images.  Yes, I know they're important, but
then so are 12-bit CT images.

- George