Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!kuhub.cc.ukans.edu!mlab2
From: mlab2@kuhub.cc.ukans.edu
Newsgroups: comp.sys.mac.programmer
Subject: Re: Large Offscreen Drawing - help please
Message-ID: <27010.2748125d@kuhub.cc.ukans.edu>
Date: 19 Nov 90 22:11:57 GMT
References: <11722@hubcap.clemson.edu>
Organization: University of Kansas Academic Computing Services
Lines: 27

In article <11722@hubcap.clemson.edu>, jcocon@hubcap.clemson.edu (james c oconnor) writes:
> A friend and I are fiddling around with off screen drawing to give zooms
> and fast scrolling on some graphical data.  On the zoom, we allocate a
> huge bitmap (16,000 by 16,000) on an offscreen port.  We then call eraseRect
> on the (0,0) and (16000,16000), but it only clears the upper left corner
> of the bitmap, and scrolling around shows dirty memory.  Aside from the
> wisdom of allocating such a large block of memory (we are PLAYING), is there
> something we are missing?
> 
> Jim

I'll second that problem.
I've noticed that the largest size I've been able to attain is 512x342.  Sound
familiar?  It's the size of my Plus's screen.
So, in creating the port, it occurred to me maybe I need to allocate a size
larger that GrafPort.  So, when I created the port, I added some large number
to the size.  No go.
Perhaps the port size needs to be told it's larger.  A call to PortSize was a
no go as well.
Clipping rect perhaps?  Expanded that.  No.
What are we missing?  VisRgn?  Is there an order that is important?  Anyone
been able to drop a large port offscreen?  As a cheap fix, I've opened several
screensize ports and used scrolling rect fragments to grab the appropriate
pieces from, say, 4 different offscreens.  CopyBit these 4 rects into one
ONscreen port.

john calhoun