Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!think.com!mintaka!bloom-beacon!dont-send-mail-to-path-lines
From: mouse@lightning.mcrcim.mcgill.EDU (der Mouse)
Newsgroups: comp.windows.x
Subject: Re:  Zooming Pixmaps
Message-ID: <9103060335.AA24850@lightning.McRCIM.McGill.EDU>
Date: 6 Mar 91 03:35:36 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 33

> What is the fastest and most convenient way to zoom (pixel
> replication would be sufficient) a 128x128 Pixmap into a 512x512
> pixmap (4x zoom)?

If - and it's a big if - your server is such that 512x512 pixmaps are
cheap, and having the server blit pixmaps around is faster than reading
them back to the client, working there, and sending them over again,
it's possible to do this entirely on the server.

This will generally not be the case, I daresay.  Such an algorithm
would be most useful when the channel between the server and the client
is of relatively low bandwidth.

The basic idea is to perform operations along the lines of

	aaaabbbbccccdddd -> aaaaccccbbbbdddd

at various scales.  In the case of magnifying a 128x128 image into a
512x512 image, I would expect this to take 14 swaps of the above form.
Since each swap costs a total of approximately ten XCopyArea() calls in
the algorithm I envision, you can see why I said what I did about this
being useful only when copying the image back to the client is slow.
(You'll also need two extra pixmaps and one or two extra bitmaps.  One
of the pixmaps can be saved at the expense of more XCopyArea()s.)

I think I have such an algorithm designed, but have not actually
written it out or tested it.  I hope to do so before long; if and when
I get it working I'll send out another note here.

					der Mouse

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