Ken.Knight@f421.n109.z1.fidonet.org (Ken Knight) (03/01/91)
Here is a question that should generate lots of answers (reply to me,
I'll summarize). Offscreen bit/pix maps are undeniably quite useful.
They are used everywhere. Now, I've seen people create grafports (and
CGrafPorts) and then access the Bit/PixMap fields of those ports after
having done the requisite setup of the any fields; I've seen people
(including me) just create a vaiarble of type BitMap or PixMap. Now,
what are the advantages of going the former way? Among other things you
have a higher memory overhead as well as the annoyance of having to
say, myPort->BitMap, instead of just MyBitMap in assignment/Toolbox
calls. Any and all comments desired.
--
Ken Knight, Ken.Knight@f421.n109.z1.fidonet.org
via The Black Cat's Shack's FidoNet<->Usenet Gateway
blkcat.fidonet.org and Fidonet 1:109/401smoke@well.sf.ca.us (Nicholas Jackiw) (03/05/91)
In article <3743.27CE88A0@blkcat.fidonet.org> Ken.Knight@f421.n109.z1.fidonet.org (Ken Knight) writes: ["What's the difference between using offscreen grafPorts and merely using offscreen portBits?"] > Among other things you >have a higher memory overhead as well as the annoyance of having to >say, myPort->BitMap, instead of just MyBitMap in assignment/Toolbox >calls. Any and all comments desired. I think the main reason people sometimes require separate ports instead of mere substituted bitmaps has to do with Quickdraw clipping. If a given port is associated with a window, it's subject to the clipping rules of the visRgn. Even if you substitute an offscreen bitmap for the screen bitmap the port normally describes, drawing to that bitmap will be clipped like drawing to the window would be. Imagine a case where a program is generating a convoluted graphic to describe a window which is occluded by some other window (e. g. background in Multifinder). Rather than recompute the entire graphic for each update, the program generates an offscreen image of the graphic that it can merely blit to the window when updates are required. If this graphic is generated in the same port as the window, with merely a separate portbits, then the actual offscreen image will only be generated in the portions of the offscreen bitmap that correspond to visible portions of the on-screen window. If this window subsequently comes to the front, the partial offscreen image isn't going to provide an aesthetically-pleasing update. On the other hand, you're right about the memory and overhead: ports are more cumbersome than simple bitmap structures--especially cPorts. The solution has to be decided on a case-by-case basis: if you're using offscreen images for a very local purpose, like rubberbanding a dragged object without XOR's hideousness, just swap to a different bitmap. If you need a more durable offscreen image, that can survive relocations, different views, etc., go with the port. A good set of routines might not cut down on the overhead, but can certainly get rid of the hassle. -- --- * --- Nicholas Jackiw Smoke@well.sf.ca.us | Jackiw@cs.swarthmore.edu Key Curriculum Press, Inc. Applelink: D3970 | (415) 548-2304 --- * ---