jkeegan@hawk.ulowell.edu (Jeff Keegan) (07/24/89)
I took the advice given to me by many people, and read tech. note #41 on
drawing to offscreen bitmaps. It had exactly the information I was looking
for. Thanks to all who replied..
However I've run into a slightly different problem now and I'm beginning
to wonder if the way I want to tackle the problem can be done. Let me
explain..
I'm writing a program that will have as part of it a "time line". For
various reasons I have decided that I want to save it as a very long (wide)
offscreen bitmap (7200 pixels), and when an update event comes along I
read my scrollbar and calculate which part of the offscreen bitmap I want to
copy to my screen.
This SEEMS to work fine at first. I have (for the sake of debugging) drawn
offscreen to my offscreen bitmap multiples of 25 up to 7200. Scrolling shows
that the bitmap is fine up to around 600 pixels, and then becomes garbage.
Here is the code I use to create the offscreen bitmap :
Rect meterRect;
GrafPtr offScreenMeter;
...
SetRect(&meterRect,0,0,METER_WIDTH,METER_HEIGHT);
offScreenMeter = (GrafPtr)NewPtr(sizeof(GrafPort));
OpenPort(offScreenMeter);
offScreenMeter->portRect = meterRect;
offScreenMeter->portBits.bounds = meterRect;
offScreenMeter->portBits.rowBytes =
(((offScreenMeter->portBits.bounds.right -
offScreenMeter->portBits.bounds.left) + 15) >> 4) << 1;
offScreenMeter->portBits.baseAddr =
NewPtr(offScreenMeter->portBits.rowBytes *
(long)(offScreenMeter->portBits.bounds.bottom -
offScreenMeter->portBits.bounds.top));
This creates it. I draw to it with :
int i;
char numstring[20];
SetPort(offScreenMeter);
EraseRect(&offScreenMeter->portRect);
for (i=0; i<= METER_WIDTH; i+=25) {
MoveTo(i-2,METER_HEIGHT-9);
sprintf(numstring,"%d",i);
DrawString(CtoPstr(numstring));
}
I have a scroll bar with min 0, max METER_WIDTH - WINDOW_WIDTH. When I have
to update the screen, I do a copybits with a destination rectangle in the
window, and a source rectangle local to the offscreen bitmap
(controlValue,0,controlValue+WINDOW_WIDTH,METER_HEIGHT). It works fine for
the first 600 pixels or so, then garbage. I think that somehow it's being
clipped by the regions of the screen (cliprgn, visrgn, etc) but I have no
idea how to get around this (I use a whole offscreen grafptr, not just a
bitmap). Is this method I want to do not possible? Was it never intended to
have 7200 pixel offscreen bitmaps? It would be real convenient for my
project if it could be done this way. Any replies would be appreciated.
..Jeff Keegan
-------------------------------------------------------------------------------
| Jeff Keegan | I clutch the wire fence until my fingers bleed |
| jkeegan@hawk.ulowell.edu | A wound that will not heal |
|----------------------------| A heart that cannot feel |
| This space intentionally | Hoping that the horror will receed |
| left blank | Hoping that tomorrow we'll all be freed -RUSH |
-------------------------------------------------------------------------------chaffee@uvm-gen.UUCP (Alex D. Chaffee,,,6581273) (07/25/89)
From article <14324@swan.ulowell.edu>, by jkeegan@hawk.ulowell.edu (Jeff Keegan): > I'm writing a program that will have as part of it a "time line". For > various reasons I have decided that I want to save it as a very long (wide) > offscreen bitmap (7200 pixels), and when an update event comes along I > read my scrollbar and calculate which part of the offscreen bitmap I want to > copy to my screen. > > This SEEMS to work fine at first. I have (for the sake of debugging) drawn > offscreen to my offscreen bitmap multiples of 25 up to 7200. Scrolling shows > that the bitmap is fine up to around 600 pixels, and then becomes garbage. ^^^ probably 512? If I remember right, Inside Mac (I, p.149) is wrong; the default ClipRgn is set to the screen. Try putting a ClipRect(&meterRect) in your creation code. For good measure, also do RectRgn(...->visRgn, &meterRect). Disclaimer: I may be wrong; all my offscreen maps have been puny. "Gee, Batman... is there anything you don't know?" "Yes, Robin. Several things, in fact." ____________________________ Alex Chaffee chaffee@emily.uvm.edu ____________________________
lipa@polya.Stanford.EDU (William J. Lipa) (07/25/89)
Just as a reminder, there is a Sample Code offering from Apple which is an offscreen bitmap package. This might provide a good example to look at. It's on sumex-aim.stanford.edu under /info-mac/apple/code and also at apple.com. I quote: These routines provide a high-level interface to the QuickDraw and Color Manager routines which allow the creation and manipulation of off-screen bitmaps and pixel maps. They are designed to run on any machine with 128K or later ROMs (sorry 64K ROM fans). Note that the design incorporates the idea that you can go along pretending there is an off-screen buffer, even when one could not be allocated, and the calls will do nothing. Bill
Greg@AppleLink.Apple.Com (Greggy) (07/26/89)
In article <1240@uvm-gen.UUCP> chaffee@uvm-gen.UUCP (Alex D. Chaffee,,,6581273) writes: > If I remember right, Inside Mac (I, p.149) is wrong; the default ClipRgn is > set to the screen. Try putting a ClipRect(&meterRect) in your creation code. > For good measure, also do RectRgn(...->visRgn, &meterRect). Well, you don't remember right. Inside Mac is correct, the clipRgn is set to a very large area. It's the visRgn that is set to the screen (as stated in the OpenPort description on Vol. I, p. 163-4). You only need to change the visRgn for things to behave properly. A side note, however: set the clip down too, so picture recording and playback don't exhibit unexpected behavior. Having a wide open clip rgn often results in overflow during scaling on playback. The result is an empty clip rgn and nothing gets drawn! (see. TechNote #59) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Greg Marriott + AppleLink: Greg + + Just Some Guy + + + "My phone is always busy" + Internet: Greg@AppleLink.Apple.Com + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Apple Computer, Inc. + + 20525 Mariani Ave, MS-46z, Cupertino, CA 95014 + + (408)974-busy + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++