home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / mac / programm / 14393 < prev    next >
Encoding:
Internet Message Format  |  1992-08-23  |  3.0 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!news.acns.nwu.edu!network.ucsd.edu!ucsbcsl!mcl!scott
  2. From: scott@mcl.ucsb.edu (Scott Bronson)
  3. Newsgroups: comp.sys.mac.programmer
  4. Subject: Re: Creating background tasks (HELP!).
  5. Message-ID: <scott.714617437@mcl>
  6. Date: 24 Aug 92 00:50:37 GMT
  7. References: <1992Aug13.170029.3055@qiclab.scn.rain.com> <1992Aug13.200535.18236@sunfs3.Camex.COM>
  8. Sender: root@ucsbcsl.ucsb.edu
  9. Lines: 63
  10.  
  11. In <1992Aug13.200535.18236@sunfs3.Camex.COM> kent@sunfs3.Camex.COM (Kent Borg) writes:
  12.  
  13. >In article <1992Aug13.170029.3055@qiclab.scn.rain.com> baer@qiclab.scn.rain.com (Ken Baer) writes:
  14.  
  15. >>What I want to do is allow our 3D rendering software to render in the
  16. >>background to the user can use the modeller etc. while rendering.
  17. >>Could someone either post, or point me to some documented code to set
  18. >>this up?
  19.  
  20. >1) When your code gets CPU time (you will know this because it is
  21. >executing) do your thing.
  22.  
  23. >2) When the user decides to say something to your running code--for
  24. >example canceling the rendering he mistakenly started--notice the
  25. >"Stop" menu choice, or "Cancel" button, or command-period keystroke,
  26. >and act on it (by stopping in this case).  
  27.  
  28. 3) Set the "accept background null events" in your size resource or you'll
  29. wait a really long time for your code to finish if you switch it to the
  30. background...  I forget to do this way too often.
  31.  
  32. >Because this is a user-oriented machine which is valuable precisely
  33. >for its user interface, be very responsive about noticing that the
  34. >user is talking to you.  Don't make the user pound on the keyboard.
  35.  
  36. Er, technically speaking the user cannot interact with your program
  37. while it is in the background.  He/she/it must switch it to the
  38. foreground to cancel the rendering.  I assume your renderer already
  39. allows cancel, so no changes here.  I believe the only two events you
  40. get while you are backgrounding are nullEvt and updateEvt and an
  41. OS activate event when you get switched back forward.  (I think...)
  42.  
  43. Pass very small values to the sleepTime parameter in WaitNextEvent
  44. (don't use GetNextEvent unless you HAVE to), and when you get time,
  45. take a tick or two and get a few more calculations again.  Then call
  46. WaitNextEvent so that other processes can get their fair time.  You
  47. can use the following loop so that you can get the processor for a
  48. fair amount of time:
  49.  
  50. // Uncompiled C code from memory below -- use at own
  51. // risk, but you get the idea.
  52. long l; EventRecord e;
  53. while( task not done ) {
  54.     if( WaitNextEvent( everyEvent, &e, 0L, nil ) ) {
  55.     HandleUpdateOrOSEvent();
  56.     } else {
  57.         l = Ticks + 2;
  58.         do {
  59.         SmallIncrementalPartOfYourTask()
  60.     } while( Ticks < l );
  61.     }
  62. }
  63.  
  64. Note that if you want to be future compatible, use TickCount() instead
  65. of the low memory global Ticks.  I use TickCount() because I figure that
  66. if Ticks ever fails, it will be trivial to re-compile using TickCount().
  67. However, none of the apps I've developed have been commercial (so far)
  68. so I haven't had to worry about expensive upgrades.
  69.  
  70. This is how I've been doing it.  If anyone has any suggestions, please
  71. do tell.
  72.  
  73.     - Scott
  74.