Hi.

>Hey, this is fun.  

YES! :)

>Goal:  I have a large image/drawing (larger than screen size) that I want
>to pan around and overlay with some alpha-blended annotations.  I want to
>present it in a window and scroll by using scroll bars and (for extra
>credit :-) by using a "hand grabber" (as in Adobe Illustrator).

Hmmm... similar to what I've been doing... I've built function plotters. 
They still have a single layer, though. They would eat a lot of memory 
otherwise!

>Currently, (using MVC :-) 

Ouch! If you switch to Morphic you won't believe it!

>1. Presuming my image will fit in a Form which I can hold in memory, how do
>I scroll this large Form around in a smaller viewport?

Morphic. Either use a formScrollerMorph or create your own 
FormScrollerMorph. You could have a non-morph object that does the form crunching and 
clipping and presents the morph the data the morph needs for scrolling and updating 
the screen. This also allows you to directly write over the world's canvas 
and this is A LOT FASTER than copying the whole form. I got this to work on the 
function plotters and you can see how the plotting algorithm works :).

>3. I've setup a release method on my window that causes any persistent
>references to it and its parts (by my objects) to be set to nil.  But I'm
>losing about 1 MB of available memory every time I create/open/close a
>TestView (suspiciously similar in size to the Form I'm creating).

This looks extremely familiar to me... I've lost lots of mbs already 
apparently for nothing. And when compressed the image takes very little space... 
hmmm...

>4. In order to avoid visual refresh glitches, I'll probably double-buffer
>the final image, i.e., do my graphic manipulations in the large, off-screen
>Form, BitBlt'ing pieces of it to the displayed Form.  

This is almost too easy to do with Morphic.

>Maybe this is the way to handle scrolling, too.  Comments?  
>Any pre-existing code I should look at?

Maybe you would like to look at the function plotters at 
www.dm.uba.ar/mathmorphs. I just got a gamma release today, and it comes with about 10 preset 
examples. I would like to send a screenshot here, but the pictures tend to be 
quite large. Can I send one to your email address? Expect something around 
200kb in GIF format (8 bit color is not that good to look at) or some more in 
other format (not jpg, it would ruin the picture).

>5. OK, already.  I should really be using Morphic.  Right?

Yes.

>Any hints?

Write directly over the world's canvas.

>Can I get the performance I need to support smooth scrolling and "hand 
grabber"
>dragging?

My experience with this is using Squeak 2.0 at 16bits, a not so fast gfx 
card and a dual 200mmx machine under NT. My gfx card is set to 1024x768x64k and 
has 2mb of dram... if Squeak's bit depth is set to 32, I have to wait an 
order of seconds of time when picking up such morphs in a morph world, when 
opening a browser and so. But for sure it's my gfx card and the color crunching 
needed to transform 32bits into 16bits, then copying the form, then updating 
the screen, then making such a big bit blt... ok:

Dragging a 640x480x64k image and bigger is HORRIBLE!
Dragging a 512x384x64k image is sluggish.
Dragging a 400x320x64k image is acceptable.
Dragging a 320x200x64k image is nice.

I'm not so sure about what is causing this. 70Hz is also killing the card. 
But I can get 60fps of raster ops at 800x600x64k under DOS... so I don't get 
a clear picture out of this. Windows video should be even faster for it's 
accelerated!... whatever. I really don't know where's the bottleneck. I've timed 
BitBlt doing such stuff and it takes about 16ms for each drag... even if it 
took 50ms it wouldn't be like this, it would allow roughly 20 drags per 
second.

>Having fun in Silicon Valley,

Grgrgrggrr... I wish I could be there! ;)

Andres.