[Gnash-dev] Gnash initialization

[Benjamin Wolsey]

Hi list,

I'd like to make using Gnash as a library easier. Currently it takes a
lot of code to get the core libraries up and running, and the design of
the code doesn't help to avoid mistakes.

Starting a SWF movie run has two stages:

1. Load and parse header. After this stage the version and initial stage
size are known.
2. Load and parse the rest of the movie; the movie is simultaneously
ready to be played.

There are also two sets of resources needed by a run:

1.  Per-run resources: 
      * sound_handler because it stores the parsed sound data (I don't
        like this design, but it's how it is) (also, in a separate
        issue, the sound handler may be split into separate classes
        eventually). 
      * Renderer because it can cache bitmaps, and above all because it
        has a handle to a single rendering buffer, so can't render more
        than one SWF at a time. 
      * StreamProvider because it stores the URLs needed for resolving
        relative URLS.

2. Per session resources
These resources can be re-used across different sessions, either
consecutively or concurrently: 
      * MediaHandler (mainly because it only generates objects as needed
        and doesn't store anything). 
      * tag loader table. 
      * MovieLibrary.
These per-session resources all seem sufficiently thread-safe;
MediaHandler because it doesn't actually share anything, the tag loader
table because it's read-only, and the MovieLibrary is mutex-protected.

So I propose the following for Gnash initialization:

A MovieFactory object will be constructed with per-session resources: 
     1. A media handler. 
     2. An optional tag loader table, using the default if not passed. 
     3. An optional shared MovieLibrary, using its own private library
        if not passed.

This MovieFactory object can be used to create a MovieRun:

MovieRun MovieFactory::createMovie(URL& url);

A MovieRun would be a trivially copyable wrapper round movie_def(not
accessible from outside), movie_root, and some other small bits of
information. It would initially give access to stage dimensions and
other information needed for setting up GUIs, videos, or whatever else
is using Gnash.

MovieRun would then have an initialize() function, taking a
RunResources, which would be used to create a movie_root, also stored in
MovieRun. This could be accessible by pointer, which is null until
initialize() is called.

RunResources should take ownership of all its resources and no longer
share them with users. The MovieRun should take ownership of the
RunResources and make the necessary elements accessible to users.

There would be no problem using multiple MovieFactory objects, each with
a different media handler, and sharing a MovieLibrary if required.

So startup would look more like the following:

MovieFactory mf(gsthandler);
MovieRun run1 = mf.createMovie(url1);
std::auto_ptr<RunResources> r1(soundhandler, renderer, streamprovider);
movie_root* mr1 = run1.initialize(r1);
assert(mr1);

// So that we can store MovieRun and access the stage.
assert(mr1 == run1.stage());
mr1->setFlashVars(vars);

MovieRun run2 = mf.createMovie(url2);
std::auto_ptr<RunResources> r2(soundhandler2, renderer2,
streamprovider2);
run2.initialize(r2);

MovieFactory mf2(ffmpeghandler);
MovieRun run3 = mf2.createMovie(url3);
std::auto_ptr<RunResources> r3(soundhandler3, renderer3,
streamprovider3);
run3.initialize(r3);

This isn't a complete plan, because it doesn't handle flashvars and
possibly other setup things, but those things should still be doable
through the movie_root available from MovieRun. From the point of view
of minimizing code changes, the MovieRun should provide the same
functions as RunResources, so that the many users of RunResources can be
changed to use MovieRun using sed.

It would require minimal changes to the interface of movie_root.

So: any ideas? There are things I'm not completely happy or sure about,
but I won't say yet what they are!

bwy

-- 
--
The current release of Gnash is 0.8.8
http://www.gnu.org/software/gnash/

Benjamin Wolsey, Software Developer - http://benjaminwolsey.de
C++ and Open-Source Flash blog - http://www.benjaminwolsey.de/bwysblog

xmpp:address@hidden
http://identi.ca/bwy

signature.asc
Description: This is a digitally signed message part