sherouse@GODOT.RADONC.UNC.EDU (George W. Sherouse) (11/15/88)
> 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
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (11/15/88)
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.
But, I lie. Note that in an XImage, depth and bits_per_pixel
are two separate things. In theory, you can create an image
that is 8 bits deep but stored 32 bits_per_pixel, and then
when you get around to sending it XPutImage will do the appropriate
conversion if the bits_per_pixel doesn't match the server.
Unfortunately, Xlib doesn't have code to implement this conversion
yet, but it's *supposed* to (small consolation, I know).
Moreover, note that things like XPutPixel are actually performed
by calling functions stored in the XImage. It is perfectly
reasonable for these functions to be specialized to the particular
image format; indeed the Xlib manual points this out. Unfortunately,
there are some crocks in the interface routines that make this
difficult (an internal Xlib routine probably needs to be exported),
but certainly that was the intention.rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (11/15/88)
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.
The tradeoff isn't absolute, but decreasing server processing time
increases overall throughput when there are distributed clients
that can do the conversions concurrently (quite possibly on
separate processors), and decreasing the server time also improves
the perceived responsiveness (yes, some nice pre-emptive scheduling
in the server would help this, but ...).
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.
It will require conversion for most hardware that I am aware of.
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.
I didn't argue against this point. I *did* argue that a more reasonable
implementation of XPutPixel in Xlib, taking advantage of the mechanisms
that are there, could remove the need for much client code to have to
make performance assumptions.
Yes, I know they're important, but then so are 12-bit CT images.
Sure. It's also good to keep in mind that XImages were not designed
to handle real image processing needs (which is not to say that it
shouldn't do what it does a whole lot faster).tmb@ganymede.UUCP (11/16/88)
> 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 Not necessarily; there are many cases in which you simply get and put pixmaps from the server without ever doing anything to them on the client. Perhaps a quick and simple solution would be to provide conversion functions in Xlib that take an XImage and a desired format and do the conversion completely on the client side.
usenet@cps3xx.UUCP (Usenet file owner) (11/16/88)
In article <8811151539.AA02975@EXPO.LCS.MIT.EDU> rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes: > > Yes, I know they're important, but then so are 12-bit CT images. > >Sure. It's also good to keep in mind that XImages were not designed >to handle real image processing needs (which is not to say that it >shouldn't do what it does a whole lot faster). OK, I'll bite. Is there any work going on that addresses image processing needs? I recall that DEC is in charge of an image processing protocol extension. What's the status of this? Are there draft documents that describe such an extension? But if I'm going to sell X as a display platform for image processing to my research group, it'd be nice if I knew what else was going on out there. (I'm kind of partial to 8-bit range data myself) ;-) thx, -- Patrick Flynn, Dept. of Computer Science, Michigan State University flynn@cpsvax.cps.msu.edu flynn@eecae.UUCP FLYNN@MSUEGR.BITNET "First we break 'em in half.... then we mash 'em to a pulp."