Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!EXPO.LCS.MIT.EDU!keith
From: keith@EXPO.LCS.MIT.EDU (Keith Packard)
Newsgroups: comp.windows.x
Subject: Re: Question about (XGetImage & XGetSubImage)'s velocity!
Message-ID: <9009160122.AA06363@expo.lcs.mit.edu>
Date: 16 Sep 90 01:22:45 GMT
References: <9009152306.AA21841@Larry.McRCIM.McGill.EDU>
Sender: tytso@athena.mit.edu (Theodore Y. Ts'o)
Organization: The Internet
Lines: 34


Somehow I missed the original message.

> > 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
>
> It seems doubtful to me that this is the problem, because you likely
> created the image with a previous XGetImage. 

The cause of the speed penalty in this case, if der Mouse is correct is that
the Xlib routines for copying data around inside images is *painfully* slow;
it is not optimized like the server side bitblt routines.

Take a look inside the routine _XSetImage (which XGetSubImage uses) - a
doubly nested loop enclosing XGetPixel and XPutPixel.  If you were writing
code, you'd be hard pressed to find a slower way to do this job. 

XGetImage doesn't need to copy the image again, so it runs much faster.

If you really want to use the functionality of XGetSubImage, I'd suggest
finding a way to do it inside the server, and then fetching the entire image
back in one step.  If you're really adventurous, you might look at the
MIT-SHM extension provided with R4 which gives you shared pixmaps between
client and server (as long as they're on the same machine).  That way you
could use the server CopyArea functions instead of GetImage for the entire
job.

Keith Packard
MIT X Consortium