thank you thomas,
this is quite extensive, and the examples mentioned on the end are (i
think) really helpfull,
i'm going to try those later!
On Jan 17, 2006, at 8:24 PM, Thomas Higgins wrote:
For the sake of debugging, have you tested this without QuickTime
in the
mix? I'm just wondering whether all this opening/closing/forgetting is
causing problems due to the player's windowing code or if there's
additional complications related to the media involved, in this case,
QuickTime. Just wondering, I know that's a side-track from your
project
and its goals but the troubleshooter in me has to ask... :)
please note that this is only a problem for me in the authoring
environment.
i have encountered the same problem in other projects, also without
quicktime.
the main symptom is that after running the movie once in authoring,
after stopping the movie and 'forget()'-ing the MIAW, the cpu stays
used for the full 100%,
as if the MIAW is still running.
in this case with a quicktime running, the payload is extra-heavy..
I still think it's worth testing with just simple windows so in
order to
make as similar a test case as possible, can you describe how often
the
window is opened and accessed in a given movie playback session (not a
Director app session!)?
the final project will only open the MIAW once and keep it opened...
Can you indicate how many times you must play
your movie and/or open this MIAW before you start to see sluggish
behavior?
...so in this case just there's no sluggish behaviour in the final
projector,
it's just the authoring env. that gets sluggish after several starts/
stops.
Can you give an overview of how much imaging you're doing? I'm
hoping to make a basic test case and let it run on a spare machine to
see what happens then float the results by our QA team for assessment.
there's quite some heavy imaging.
that's what makes it so important that it also runs smooth in
director itsself..
i'm running a 'pinch' algorithm on parts of the image i copied from
the MIAW,
and then make a composition of the original quicktime plus the pinch-
image and some additional layers on the main stage.
i hope to run this on full 1024x768 in the end.. first results look
promising on a G5.
but need to restart director every 2 or 3 runs, to be able to debug
and really tweak performance.
You are correct in that the way to image a playing QT movie is to have
it on stage as a non-DTS sprite, then grab the image of the stage
containing that sprite. You might also consider playing with the
window's rect and drawRect (stage or otherwise) to have the video on
stage yet clipped from the window viewport similar to how I've done it
here:
now that's a really great suggestion.
i understand that you want to understand and solve the bug/problem i
posed,
but this i a great way for me to get around the need to restart
director each time.
and is this possibly also more efficient than using a MIAW?
<http://poppy.macromedia.com/~thiggins/articles/videotextures/
_archive/i
ndex.htm>
The above is an example of using QT imaging to render the video's
image
as a texture in a simple 3D scene. Since MIAWs aren't supported we
must
use techniques that allow the video to be on stage yet hidden from the
user's eyes. Try something like that if you need an alternative.
Although given that the problems you're citing pertain to author-time
woes I don't know that it'll be worth the dev hassle as the end user
won't notice this issue anyway. But obviously that's up to you, I hope
this helped somehow.
this help very much. at least for me in developing time.
as i've experienced this MIAW-problem before, i'll keep an eye open
and try to discover a pattern in this behaviour, and post my findings
if i do.
for now,
thank you very much.
hope to be able to follow-up on this.
gr
\rri
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/lingo-l.cgi To post messages to the list, email
[email protected] (Problems, email [EMAIL PROTECTED]). Lingo-L is for
learning and helping with programming Lingo. Thanks!]
