brian@radio.toronto.edu (Brian Glendenning) (03/28/88)
[My apologies if you've already seen this, but I'm pretty sure it got lost
in-campus]
Does anyone have a piece of code to do a fast zoom to a window under suntools?
I have a program that acts as a graphics server to a large astronomy package,
and every last little bit of speed will be felt.
What I'm now doing is stepping through the image a line at a time, zooming that
line into a temp array by "hand", and then pw_rop'ing the zoomed line into the
screen. That is:
111000111000111000111000111000
1010101010101010 Zoom by 3 (say) ---> 111000111000111000111000111000 -> pw_rop
111000111000111000111000111000
(original image line) (zoomed temp array)
While this is a lot faster than some of my earlier efforts, I thought I'd ask
if anyone had any really fast code, or suggestions. For instance, I'm doing an
incore transfer that in principle isn't necessary if I wrote to screen memory,
but I'm not quite sure how to do that, especially if one wants to worry about
overlapping windows etc. My code now takes a couple of seconds to zoom the full
screen (colour sun 3/180).
Any advice, programs, or code fragments would be much appreciated. Thanks.
--
Brian Glendenning INTERNET - brian@radio.toronto.edu
Radio Astronomy, U. Toronto UUCP - {uunet,pyramid}!utai!radio!brian
+1 (416) 978-5558 BITNET - glendenn@utorphys.bitnetallan@calgary.UUCP (Jeff Allan) (03/31/88)
In article <1054@radio.toronto.edu>, brian@radio.toronto.edu (Brian Glendenning) writes: > Does anyone have a piece of code to do a fast zoom to a window under suntools? > I have a program that acts as a graphics server to a large astronomy package, > and every last little bit of speed will be felt. > 111000111000111000111000111000 > 1010101010101010 Zoom by 3 (say) ---> 111000111000111000111000111000 -> pw_rop > 111000111000111000111000111000 > > (original image line) (zoomed temp array) I'm not really familiar with the Sun but is occurs to me that there is a fast raster copy primitive that operates in the screen buffer. If this is the case then I suggest you use it to "fatbits" your image in two passes: one for vertical and one for horizontal. To double the upper-left corner of a 100 by 100 image (origin in upper-left): for (r=49; r>=0; r--) { pw_copy row(r) into row(2*r) and row(2*r+1) } for (c=49; c>=0; c--) { pw_copy col(c) into col(2*c) and col(2*c+1) } Hope this helps. -- Jeff Allan, University of Calgary ..!{ubc-vision,ihnp4}!alberta!calgary!allan
miner@dino.ulowell.edu (Rich Miner) (04/04/88)
In article <1054@radio.toronto.edu> (Brian Glendenning) writes: >Does anyone have a piece of code to do a fast zoom to a window under suntools? If you can deal with byte boundary's you can build a 255 element look up table that takes in a byte and spits out the desired result. Look up table methods of scaling and dithering work very fast and are not very difficult to code. -- Rich miner@ulowell.edu 617/452-5000x2693 ULowell CPE Imaging Research Lab
hirai@swatsun.uucp (Eiji "A.G." Hirai) (04/05/88)
brian@radio.toronto.edu (Brian Glendenning) writes: > > Does anyone have a piece of code to do a fast zoom to a window under > suntools? I don't know if this is want you want but if you're looking for something like a magnifying glass, then Scott Schwartz has written just such an application. It's in the latest Sun Users Group tape distribution. He can also be contacted at the following address. schwartz@gondor.cs.psu.edu ...!psuvax1!gondor!schwartz If I totally mistook your question, I apologize. Just a plug for our former sysadmin. :-) -- Eiji "A.G." Hirai @ Swarthmore College, Swarthmore PA 19081 | 215-543-9855 UUCP: {rutgers, ihnp4, att-cb}!bpa!swatsun!hirai | "All Cretans are liars." Bitnet: vu-vlsi!swatsun!hirai@psuvax1.bitnet | -Epimenides Internet: swatsun!hirai@bpa.bell-atl.com | of Cnossus, Crete
barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) (04/22/88)
In article <1726@thebes.UUCP> hirai@swatsun.uucp (Eiji "A.G." Hirai) writes: |brian@radio.toronto.edu (Brian Glendenning) writes: | I don't know if this is want you want but if you're looking for |something like a magnifying glass, then Scott Schwartz has written just |such an application. It's in the latest Sun Users Group tape |distribution. That program doesn't magnify anything. All it does is copy the rastermap near the cursor and display it THE SAME SIZE in the window of the tool. -- Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> uunet!steinmetz!barnett
jbn@glacier.STANFORD.EDU (John B. Nagle) (04/22/88)
A magnifying cursor has been seen on Dorados up at Xerox PARC. The Dorado has enough power to make it work smoothly. I'd like to see one for CAD applications. John Nagle
schwartz@gondor.cs.psu.edu (Scott Schwartz) (04/22/88)
In article <4233@vdsvax.steinmetz.ge.com> barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) writes: >In article <1726@thebes.UUCP> hirai@swatsun.uucp (Eiji "A.G." Hirai) writes: >| I don't know if this is want you want but if you're looking for >|something like a magnifying glass, then Scott Schwartz has written just >|such an application. It's in the latest Sun Users Group tape >|distribution. > >That program doesn't magnify anything. All it does is copy the >rastermap near the cursor and display it THE SAME SIZE in the window >of the tool. No, no no! Glass takes a command line argument giving the magnification factor (defaulting to 1) and (in version 2.x) has a panel slider so you can change magnification on the fly. The version on the SUG tape is 2.1, I think. By the way, the sliders and other enhancements were done by Mark Weiser <weiser@parcvax.xerox.com>. -- Scott Schwartz schwartz@gondor.cs.psu.edu schwartz@psuvaxg.bitnet
hunt@spar.SPAR.SLB.COM (Neil Hunt) (04/23/88)
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/.