Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!usc!apple!snorkelwacker!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse
From: mouse@LARRY.MCRCIM.MCGILL.EDU
Newsgroups: comp.windows.x
Subject: Re:  Question about (XGetImage & XGetSubImage)'s velocity!
Message-ID: <9009152306.AA21841@Larry.McRCIM.McGill.EDU>
Date: 15 Sep 90 23:06:33 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 30

> The problem: I'd like to do some rudimentary screen dumps and if
> possible, very quickly.  I can do that using XGetImage or
> XGetSubImage.  The manual says that XGetImage allocates both the
> XImage structure and the space for the image itself, but XGetSubImage
> just updates the XImage structure passed as argument.  In some cases,
> I want to update an existing XImage, so, XGetSubImage seems to be a
> good way... :-( but... it's *SLOWER* than XGetImage (which creates a
> new one).

> I do some screen dumps (image size: 300x300):
>	with XGetImage, it takes about 0.1 s.
>	with XGetSubImage, it takes more than 5 s.

One possibility is that the existing XImage you're updating with
XGetSubImage does not use the server's "natural" bit order and byte
order, forcing XGetSubImage to do conversions instead of just dumping
the data in as received from the wire.  XGetImage, which can create the
XImage with whatever bit and byte order it finds convenient, doesn't
have to handle each pixel; it can just copy the data from the wire to
the image's data area directly.

It seems doubtful to me that this is the problem, because you likely
created the image with a previous XGetImage.  It may be that your
library's XGetSubImage is stupid and handles the pixels individually
even when it doesn't have to.

					der Mouse

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