home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / mac / programm / 12964 < prev    next >
Encoding:
Internet Message Format  |  1992-07-23  |  2.4 KB
  1. Path: sparky!uunet!sun-barr!apple!apple!NewsWatcher!user
  2. From: dowdy@apple.com (Tom Dowdy)
  3. Newsgroups: comp.sys.mac.programmer
  4. Subject: Re: How do I sleep w/o using any CPU time
  5. Message-ID: <dowdy-200792081218@90.10.20.25>
  6. Date: 20 Jul 92 15:15:13 GMT
  7. References: <0105011F.8acslo@dragon.enigami.mv.com> <1992Jul13.150027.4926@usenet.ins.cwru.edu>
  8. Sender: usenet@Apple.COM
  9. Followup-To: comp.sys.mac.programmer
  10. Organization: Apple Computer, Inc.
  11. Lines: 39
  12.  
  13. In article <1992Jul13.150027.4926@usenet.ins.cwru.edu>, yjc@po.cwru.edu
  14. (Jerome Chan) wrote:
  15. > 
  16. > In article <0105011F.8acslo@dragon.enigami.mv.com> Cory Kempf,
  17. > cory@enigami.mv.com writes:
  18. > >The way to give up the CPU is to call WaitNextEvent, passing it a
  19. > >large number of the 3rd parameter (time that WNE can give away). 
  20. > >I usually use 50 or so (there was this bug a while back...).  By putting
  21. > >this inside a while loop that checks the tickcount, I give away as
  22. > >much CPU as I can.  
  23. > 
  24. >   Hmm. But won't we be losing events if we do this? If windows are being
  25. > displayed and the user switches to another application under
  26. > multi-finder, won't we lose the the Update Event? Or is that the
  27. > Resume/Suspend Event?
  28.  
  29. Actually, you won't be losing events - however, there is a potential
  30. serious
  31. problem with calling WNE this way all of the time.  Note that in *this*
  32. particular case, the original poster (long since gone from this discussion,
  33. I would fear) wasn't going to have any windows open - he was simply running
  34. until an event happened, at which time a dialog box would be brought
  35. up (no doubt saying something such as "Your rendering is complete").
  36.  
  37. However, if you *do* have windows open, and fail to respond to update
  38. events, you will see very sluggish performance on your Mac as the
  39. process manager attempts to give you updateEvents over and over again.
  40. Eventually, when it sees some very large number of update events go
  41. by for the same window, it will assume you are clueless and clear
  42. the updateRgn itself - however, this takes almost a minute and a half.
  43.  
  44. The thing to learn is - always handle update events, and always call
  45. BeginUpdate()/EndUpdate() when handling them.
  46.  
  47.  Tom Dowdy                 Internet:  dowdy@apple.COM
  48.  Apple Computer MS:81KS    UUCP:      {sun,voder,amdahl,decwrl}!apple!dowdy
  49.  20525 Mariani Ave         AppleLink: DOWDY1
  50.  Cupertino, CA 95014       
  51.  "The 'Ooh-Ah' Bird is so called because it lays square eggs."
  52.