jcocon@hubcap.clemson.edu (james c oconnor) (11/20/90)
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
francis@daisy.uchicago.edu (Francis Stracke) (11/20/90)
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? Isn't that enough? Have you thought about just how huge this is? RowBytes=2000, for God's sake! This means you would need 32G to hold the damned thing! If you've got 32 gigabytes in your Mac, please tell me what decade you're going to buy it! | Francis Stracke | My opinions are my own. I don't steal them.| | Department of Mathematics |=============================================| | University of Chicago | Non sequiturs make me eat lampshades | | francis@zaphod.uchicago.edu | |
darweesh@zephyrus.crd.ge.com (Michael Darweesh) (11/20/90)
You must make sure that the visRgn and the clipRgn of the port that you're working with include your whole bitmap. Normally, the visRgn and clipRgn are inherited from the standard (I forget the word right now) port. Make sure that these are correct and that the portRect is correct too. Everything should be fine then. I usually set the portRect and then convert this to a Rgn directly into the port's visRgn variable. (use the RectRgn procedure) There is no "SetVisRgn" call, so you basically have to do it manually-no big deal. If you have problems, feel free to send me private e-mail. I've done this...but I may have flubbed something up-I wrote it and just cut & paste it now. :-> -Mike Darweesh weesh@crd.ge.com
mlab2@kuhub.cc.ukans.edu (11/20/90)
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
Invader@cup.portal.com (Michael K Donegan) (11/20/90)
Check out the documentation on OpenPort/InitPort. The portRect and visRgn are both set to the size of screenBits.bounds, so you must make them larger. The clipRgn is set relatively wide open (about as wide as you want to get really.) mkd
emmayche@dhw68k.cts.com (Mark Hartman) (11/21/90)
In article <1990Nov19.205344.9317@midway.uchicago.edu> francis@daisy.uchicago.edu (Francis Stracke) writes: >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? > >Isn't that enough? Have you thought about just how huge this is? >RowBytes=2000, for God's sake! This means you would need 32G to hold >the damned thing! If you've got 32 gigabytes in your Mac, please >tell me what decade you're going to buy it! 32 GIGAbytes? I thought 2000 bytes * 16000 rows = 32,000,000 bytes or 32Mb. This is still way too much - but how'd you figure 32,000,000,000 bytes? To James: this sounds like a great way to crash your Mac. Try a smaller bitmap, and make sure that your clipRgn for your offscreen port is as large as it can be (generally a rectangle [(-32767,-32767),(32767,32767)], otherwise known as "mobyBigRect"). >| Francis Stracke | My opinions are my own. I don't steal them.| >| Department of Mathematics |=============================================| >| University of Chicago | Non sequiturs make me eat lampshades | >| francis@zaphod.uchicago.edu | | -- ========================================================================= Mark Hartman, N6BMO |"What are you standing uucp: ...{spsd,zardoz,felix}!dhw68k!emmayche |there for? Where do Internet: emmayche@dhw68k.cts.com |you think you are,
russotto@eng.umd.edu (Matthew T. Russotto) (11/21/90)
In article <27010.2748125d@kuhub.cc.ukans.edu> mlab2@kuhub.cc.ukans.edu writes: >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? Bingo. VisRgn is honored for offscreen ports, contrary to IMI, so when you create a port, after the normal port creation calls: SetRectRgn(p->visRgn, p->portRect); -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu .sig under construction, like the rest of this campus.