home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / mac / programm / 13967 < prev    next >
Encoding:
Internet Message Format  |  1992-08-13  |  2.8 KB
  1. Path: sparky!uunet!usc!sol.ctr.columbia.edu!caen!uakari.primate.wisc.edu!ames!agate!rsoft!mindlink!a347
  2. From: John_Miller@mindlink.bc.ca (John Miller)
  3. Newsgroups: comp.sys.mac.programmer
  4. Subject: LockPixels and dereferenced PixMapHandles
  5. Message-ID: <14278@mindlink.bc.ca>
  6. Date: 14 Aug 92 00:59:06 GMT
  7. Distribution: world
  8. Organization: MIND LINK! - British Columbia, Canada
  9. Lines: 63
  10.  
  11. In various portions of code on the developer CD, it seems to be
  12. assumed that once LockPixels() is called, it's safe to dereference
  13. the PixMapHandle when calling CopyBits.  Here's one example
  14. from the file
  15.    "Dev.CD June 92:
  16.       Periodicals:
  17.         develop:develop 10 code:
  18.           GWorld Drawing:
  19.            GWorld Routines:
  20.             CalcDeltasFast.c"
  21.  
  22. >       srcPixMap = GetGWorldPixMap ( src );
  23. >       dstPixMap = GetGWorldPixMap ( dst );
  24. >
  25. >       if ( LockPixels ( srcPixMap ) && LockPixels( dstPixMap) )
  26. >       {       /* lock the pixmaps */
  27. >               GetGWorld(&oldGW,&oldGD);
  28. >               SetGWorld(dst,nil);
  29. >               CopyBits( (BitMap*)*srcPixMap, (BitMap*)*dstPixMap,
  30. >                &(**srcPixMap).bounds, &(**dstPixMap).bounds,
  31. >                srcCopy, 0L );
  32.  
  33. But from my reading of Inside Mac, LockPixels() only locks the
  34. memory used to hold the pixels, not the PixMapHandle itself.
  35. And when I check this in MacsBug, sure enough, the
  36. PixMapHandle is not locked by LockPixels() or unlocked by
  37. UnlockPIxels().
  38.  
  39. If I had picked up this code on the street, I would simply
  40. assume it was buggy, but seeing as I find this in various
  41. fragments of Apple code, I'm wondering if I am missing
  42. something.
  43.  
  44. Two questions:
  45.  
  46. 1)  Should the PixMapHandle be locked before dereferencing
  47. it to pass to CopyBits, or am I missing some piece of
  48. Mac programming forklore that guarantees that CopyBits
  49. will extract all the required information from parameters
  50. before it causes any memory shuffling?
  51.  
  52. 2) Assuming that I would have to lock the PixMapHandle
  53. before using in the above example: is it considered valid
  54. to copy the PixMap structure contents to a local PixMap
  55. variable and pass the address of the variable to CopyBits,
  56. or does CopyBits assume that the address it is passed can
  57. be traced back to a PixMapHandle?  Right now, my
  58. offscreen utility routines are calling MoveHHi(pixmap)
  59. and HLock(pixmap) after calling LockPixels(), but I would
  60. like to avoid the potential expense of MoveHHi and
  61. the potential memory fragmentation if I lock the handle
  62. without calling MoveHHi.
  63.  
  64. (Seeing as the current CopyBits won't use the application
  65. heap for any image buffers, I suppose I could lock
  66. the PixMapHandle only before CopyBits -- thus avoiding
  67. fragmentation for other calls such as DrawPicture --
  68. but I would prefer an approach that would continue
  69. to work well if CopyBits' implementation details
  70. change.)
  71.  
  72. John Miller
  73. Symplex Systems
  74.