2006/11/27, Rob Savoye <[EMAIL PROTECTED]>:
Another thing I'm considering is making *all* the ActionScript classes plugins.
Lovely idea. I am only worried about slower startup or lumpy playback. It's a situation analogous to static linking vs shared library loading, and a quick test between bash and bash-static shows bash, which only has 4 shared library dependencies, taking exactly twice as long to start up as bash-static (40ms instead of 20 on a 200MHz arm, half user time half system time) with both preloaded into the cache, so no disk-access time is included. I'm not suggesting anyone link gnash statically (with disk-access time included that is actually slower cos many shared libraries are already in core from other processes). I'm just saying that putting all actionscript classes into separate files instead of having a common subset in the executable may have a non-trivial startup penalty on slow systems. Kernel-module type yes/no/module config, anyone? :-/ Full modularisation might have the additional advantage of giving a way to get round any flash8/flash9 incompatibilities that turn up, since adobe, having 2 separate engines if I understand correctly, may not need to keep <=8 and >=9 versions method-compatible, tho I may be talking rubbish here. M _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
