acmfiu@serss0.fiu.edu (ACMFIU) (02/21/91)
In an effort to figure out how in the world to do this (and it is driving me up the wall) i did the following: when you create a window, a GrafPort is created. So, i allocated memory for 32K of memory for the screen and changed the pixel map pointer in the LocInfo record int he GrafPort data structure to this area of memory thinking that QuickDraw would "know" that it is NOT the same address as the screen ($e12000) and thus not add the extra overhead for writing directly to the screen. I then copied the contents of the screen to my pointer (PtrToHand) and then did the updates to the window and then copied the info back to the screen (HandToPtr). I was hoping this would speed things up but it did absolutely nothing for speed. It seems that QuickDraw is not "smart" enough to figure this out. What in the world is so darn hard about making an off-screen GrafPort? Any Apple DTS people out there want to answer this, please! Maybe I don't fully understand QuickDraw because the manuals don't seem too enlightening to me. I tried OpenPort once and moved the portInfo rectangle off the screen but that didn't seem to help at all. When the portInfo rectangle moves, does the pixelmap move with it? I also tried SetOrigin but who knows what this does. Aren't tools suppose to make things easier. Right now I just feel like writing my own graphic tools and say goodbye to compatibility with all the other desktop programs. But then when this thing is finally figured out I'll say, "now wasn't that easy?". albert
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (02/22/91)
acmfiu@serss0.fiu.edu (ACMFIU) writes: >thinking that QuickDraw would "know" that it is NOT the same address as >the screen ($e12000) and thus not add the extra overhead for writing directly >to the screen. What overhead? There is no overhead for writing directly to the screen other than the slow writes to the $e1 buffer; they aren't the primary time waster, however. There IS a lot of overhead for drawing things that have to be clipped, which is where people seem to be having problems. QuickDraw's region processing is beastly slow, and since the window manager uses it extensively to draw overlapping windows, accelerators become an attractive option. Quickdraw itself doesn't care where the pixel map is, except for the cursor routines and such. What you need to do is create an offscreen grafport (do this with OpenPort and SetPortLoc) and draw your stuff into the offscreen grafport. When you want to update your window, use PaintPixels or PPToPort. Correct me if I'm wrong, but you want to reduce the number of times you have to draw the objects you're displaying in the window. The method I just described allows you to keep an offscreen image and issue a single call to update your window, which is what I believe you are looking for. >It seems that QuickDraw is not "smart" enough to figure this out. What in >the world is so darn hard about making an off-screen GrafPort? Nothing. On off-screen GrafPort is any GrafPort whose LocInfo field has been replaced or modified -- I've studied the QD chapter and the tech notes about it, and I think I'm beginning to understand what all is going on. There's a tech note that will probably help you a lot -- I'll put it up on tybalt.caltech.edu in pub/apple2/transfer; mail me if you don't have FTP. > Maybe I don't fully understand QuickDraw because the manuals don't seem too >enlightening to me. There weren't too enlightening to me either. IIgs technote 80, QuickDraw II Clipping, explains quite a bit and makes sense of the toolcalls you mentioned. It's on tybalt now, and will be in pub/apple2/transfer by the time you read this. Todd Whitesel toddpw @ tybalt.caltech.edu