home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / mac / hypercar / 4109 < prev    next >
Encoding:
Text File  |  1992-11-08  |  3.9 KB  |  90 lines
  1. Newsgroups: comp.sys.mac.hypercard
  2. Path: sparky!uunet!ukma!usenet.ins.cwru.edu!agate!rsoft!mindlink!a347
  3. From: John_Miller@mindlink.bc.ca (John Miller)
  4. Subject: Re: quicktime and hypercard
  5. Organization: MIND LINK! - British Columbia, Canada
  6. Date: Fri, 6 Nov 1992 22:44:19 GMT
  7. Message-ID: <17208@mindlink.bc.ca>
  8. Sender: news@deep.rsoft.bc.ca (Usenet)
  9. Lines: 79
  10.  
  11. In an article whose number I forgot to save :), Lawrence D'Oliveiro
  12. writes
  13. >In article <16917@mindlink.bc.ca>, John_Miller@mindlink.bc.ca (John Miller)
  14. >writes:
  15. >>
  16. >> [As an aside, when I read the description of EnterMovies and
  17. >> ExitMovies -- particularly the clarification in Apple's
  18. >> DTS Q&A Stack -- I don't see how any XCMD that plays
  19. >> QuickTime movies asynchronously can guarantee compatibility
  20. >> both with the current version of HyperCard (which knows
  21. >> nothing of QuickTime) and a future version of HyperCard
  22. >> (which will presumably know of, support, and initialize
  23. >> QuickTime).
  24. >
  25. >So the XCMD calls EnterMovies before it loads and starts the movie playing,
  26. >and ExitMovies after it's stopped and disposed of the movie. You can have
  27. any
  28. >number of such calls running concurrently, or overlapping, or whatever.
  29. >A future version of HyperCard might call EnterMovies when it starts up,
  30. >and ExitMovies when it quits. In each case, the number of ExitMovies calls
  31. >equals the number of EnterMovies calls, and the lifetime of each currently-
  32. >loaded movie always lies within at least one pair of EnterMovies/ExitMovies
  33. >calls at every point. So what's the problem?
  34.  
  35. EnterMovies/ExitMovies are documented to setup/dispose private
  36. state information for the Movie Toolbox.  The problem I have
  37. is that the Movie Toolbox Q&A says that multiple calls to
  38. EnterMovies -- rather than incrementing a usage counter
  39. for the QuickTime world associated with that A5 world --
  40. allocates and sets up a new QuickTime world.
  41.  
  42. Consider a mythical future HyperCard 3.0 which contains
  43. built-in QuickTime support.  Here is a possible sequence.
  44.  
  45. 1) Hyp 3.0 starts up and calls EnterMovies, creating
  46.    QuickTime World A.
  47. 2) A script makes use of a NiftyMovie XCMD to start playing
  48.    Movie1 asynchronously.  (It has some nifty feature
  49.    that isn't provided in Hyp 3.0's built-in support).
  50.    As part the XCMD's initialization, EnterMovies is called,
  51.    creating QuickTime World B and making it the current
  52.    QT world.  Movie1 starts to play.
  53. 3) A script now is invoked that starts playing Movie2
  54.    using HyperCard's built-in support. Presumably,
  55.    Hyp 3.0 would make no call to EnterMovies at this
  56.    point.  Movie2 is created "into" the current QuickTime world,
  57.    World B.  Movie2 is a nice long movie.
  58. 4) Movie1 finishes playing.  NiftyMovie XCMD cleans up
  59.    after itself and calls ExitMovies.  This disposes
  60.    of QuickTime World B and returns QuickTime World A
  61.    to being the "current QuickTime world."
  62.  
  63. At this point, Movie2 is still playing but the QuickTime
  64. world it "belongs to" no longer exists.  This strikes
  65. me as a rather ill-defined situation.
  66.  
  67. Actually, the same problem occurs now with overlapping
  68. movies -- where each movie can end up calling ExitMovies
  69. on the QT world set up by the other movie's EnterMovies --
  70. and it doesn't seem to do the current version of QuickTime
  71. any harm.  So, perhaps the only implication is that Apple
  72. -- when creating new versions of QuickTime -- faces greater
  73. restrictions on what data structures can be a part of QuickTime's
  74. private state data.
  75.  
  76. But in any case, my original aside was wrong because
  77. an XCMD could avoid all gray areas by ensuring a
  78. unique A5 for each asynchronous movie.
  79.  
  80. I guess this is just an overly long way of saying "nevermind." <grin>
  81. (I still don't understand/like this "allocate new state globals
  82. for every EnterMovies call" -- how does MoviesTask access an
  83. application's movie list if not via the state globals? -- but I
  84. guess arguing the matter in the face of the current no-problem
  85. implementation will just serve to make me look silly.)
  86.  
  87. John Miller
  88. Symplex Systems
  89.  
  90.