Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!umd5!purdue!decwrl!spar!hunt
From: hunt@spar.SPAR.SLB.COM (Neil Hunt)
Newsgroups: comp.graphics
Subject: Re: Fast Zoom for Suns
Message-ID: <297@spar.SPAR.SLB.COM>
Date: 22 Apr 88 18:31:19 GMT
References: <1054@radio.toronto.edu> <1726@thebes.UUCP> <4233@vdsvax.steinmetz.ge.com> <17410@glacier.STANFORD.EDU>
Reply-To: hunt@spar.UUCP (Neil Hunt)
Organization: SPAR - Schlumberger Palo Alto Research
Lines: 93

I have implemented a magnifier within software running on Suns in two
applications; they are both quite fast (better than 10 refreshes a second
for 64 x 64 pixel of magnifier size).

One of these is a display tool for digitised images, in support of
our vision and graphics work. The magnifier works best at 64 x 64
with a linear magnification of 4.

The other is implemented in `dvipage', my grey-scale fonts DVI previewer.
Here, I render a page of typeset characters into a 1 bit memory pixrect
(packed binary array) at high resolution (300 dpi), perform spatial
filtering and sample down (now in grey scale) to a small array for display
on the screen. The display in grey scale retains much greater readability
than the same spatial resolution binary fonts, but at 3 pixels by 2 for
small characters (subsubscripts in 10pt, for example), a magnifier is
very useful. In this case, of course, I have a representation at high
resolution available, and it is just a question of ropping (BLTing)
it onto the screen.

The following points are relevant to implementors:

1. It helps if you have a suitable representation of the data to be
   magnified. That is, my magnifier only works over the application window;
   it is NOT a general magnifier that expands anything over which it passes.
   In the display tool, I have a representation of the image being displayed
   which I can work with faster than with a pixrect. In the previewer,
   the situation is even better, as I have a magnified image already
   available.

   Reading the bits from the screen, magnifying, and redisplaying them
   is too costly. Especially when dealing with different colour maps
   as you pass from window to window. Handling the display lock, the
   repaint requests, etc, etc: FORGET IT.

2. One of the major problems, especially when the magnification is fast,
   is that putting the bits on the screen is the bottleneck.
   Consider the obvious loop:

	while(! button is up)
	{
		compute magnification of region.
		if(! first_time)
			erase previous magnifier
		paint new magnifier
		read new cursor position.
	}

   If you erase the whole of the previous magnifier (by repainting
   the bits which used to be there), about half of the time the screen
   will be showing the UNmagnified bits rather than the magnified bits,
   and there will be a horrible flashing as the paint and erase interact.

   The trick is to observe that the magnifier usually only moves a few
   pixels, and that much of it overlaps the old position. You don't
   need to erase this overlapped portion, only the portion of the
   `damaged' window which has been uncovered by the motion of the magifier
   region. Something like this:

	dx = new_x_position - old_x_position
	dy = new_y_position - old_y_position
	if(dx > 0)
		paint strip from old_x_position to new_x_position.
	else if(dx < 0)
		paint strip from new_x_position+width to old_x_position+width
	/* else dx == 0, so dont paint vertical strips. */
	if(dy > 0)
		paint strip from old_y_position to new_y_position.
	else if(dy < 0)
		paint strip from new_y_position+height to old_y_position+height
	/* else dy == 0, so dont paint horizontal strips. */

3. Dvipage, the DVI previewer is in the public domain, including the
   magnifier code. It doesn't contain the code used in my display tool
   which actually expands the image by pixel replication (that's the
   easy bit, anyway), but it does contain the rest. Especially useful
   is the function `pw_cover()' which is like pw_rop, except that it
   guarantees to paint the entire destination rect, as opposed to
   pw_rop which only paints the region for which it can obtain pixels
   from the source image. (Pw_cover paints the PIX_COLOR() mixed with
   the op argument in such areas).

   The magnifier in dvipage updates at about 20 frames per second
   (at least, much faster than I can count) even at a size of 512 x 512
   pixels !

   You may be able to get this from the UnixTeX distribution,
   or from the SunSpots archives, or from comp.sources.unix; I sent it
   to all three about two weeks ago; it hasn't appeared yet in either
   Sun-spots, or in comp.sources.unix (at least not before yesterday --
   I havn't got to those groups yet).

Enjoy,

Neil/.