Re: [Gnash-dev] Re: SWF streaming

[strk]

I committed a first implementation of a separate loading
thread. elvis.swf and intro1.swf are both playing fine
(the problem with the latter was waiting too much on WaitForFrame
tag, with the first being too slow initially).

We now have a separate thread which is started right after SWF
header has been parsed. As before, sprite_instance::advance_root
waits for next "chunk" of frames to be loaded, but now a chunk
is defined to be composed of a single frame, so most of the time
there's no wait at all.

Beside cleaning code up (load_next_frame_chunk doesn't make sense anymore)
a next step would be stopping the loading thread while rendering and
executing actions of any frame (unless next load is really needed to
advance). This should remove the initial syncopatic experience
with elvis.swf.

--strk;

On Sat, Aug 12, 2006 at 03:19:10PM -0600, Rob Savoye wrote:
> strk wrote:
> 
> > I thought we were avoiding threads, but if everyone is ok with
> > it I will inspect possibilities for it. Actually a thread would
> > be a convenient solution as the thread could be removed as soon
> > as the movie is fully loaded.
> 
>   Exactly. For GameSWF, thread usage was discouraged, but I'm a big fan
> of using POSIX threads. In fact, I'd like to use the "Fast Events for
> SDL", which uses a background thread to pump the SDL event loop at a
> much higher rate.
> 
> > The only problem I can think of is at frame-advance time, in case the next
> > frame has not been loaded yet. We'd likely want to render the frame as soon
> > as it's loaded rather then skip the operation and wait next 1/FPS seconds.
> 
>   You could use a POSIX condition variable that if it's set, it'd stall
> till the frame is loaded. When loaded, the background thread would clear
> the mutex for the condition.
> 
>   Don't forget to use mutexes for any global variables that may get
> modified by both threads.
> 
>       - rob -