From Gnash Project Wiki
Movies can be loaded dynamically by an SWF application by means of: - MovieClip.prototype.loadMovie - MovieClipLoader.prototype.loadClip
In both cases the loaded movie can be an SWF or a Bitmap.
Neither of those calls should be blocking, but should rather happen in background.
At time of writing (gnash 0.8.5) the external resource parser is initialized in a blocking way. Parser initialization can be fully (for bitmaps) or partially (for SWF) blocking. Partial blocking means that initialization only parses a portion of the external data. Full blocking means the external data is completely parsed before returning.
The minimum partial load is the 3 bytes of magic number, which can be a long time due to DNS resolution and socket initialization.
For bitmaps this is even worst as it takes full download before proceeding.
Plan for an asyncronous load mechanism
In order to make loading completely unblocking we need to setup a central loading service which uses callbacks to signal progress and completion of loading and maybe also parsing.
The needed callbacks are different based on the kind of load.
For a simple loadMovie() request we don't need much more than a target string which would be seeked to drop-in a new instance of the parsed definition.
For loadClip() (MovieClipLoader interface) we also need an object (the MovieClipLoader instance) to signal onLoadStart, onLoadInit, onLoadComplete, onLoadError and onLoadProgress.
The closest current support for async load is the movie_root::loadMovie interface which "queues" load requests and process them as part of its heart-beat duties. It currently only takes a target so can be used for loadMovie() but not for loadClip() which lacks at least an object to signal all the required callbacks.
Centralization of movie load has been committed in r11615. Now is time to unblock those blockages.