Shumway should have a build target that is a single file and that is easy to embed into other projects.
Shumway.js could emulate SWFObject's API to provide Flash Player detection with automatic fallback to Shumway.
Priority: -- → P3
Do we have to bundle everything in a single file? Currently, according to me, the shumway is embedded using 2 iframes, one of them including shumway.gfx.js (also it's own JS file, viewer.js) and other including including shumway.player.js(also it's own JS file, viewer.player.js). There is a solution where we can have a JS file(say shumway.js) which can dynamically generate these iframes including all these JS files(using <script> tags) . Basically, generating the entire HTML DOM dynamically. But this will then depend on the location of shumway.gfx.js and shumway.player.js. We can embed the entire code of all JS files in a single JS file (shumway.js file), and remove the dependencies of the locations of these JS files. But there are dependenices of locations of shaders in viewer.js and dependencies of abc files in viewer.player.js. So, I am unable to actually decide what to do or whether I am going in the right direction.
Basic code landed at https://github.com/mozilla/shumway/pull/2031 and the shuobject library is available at http://www.areweflashyet.com/shumway/shuobject/shuobject.zip . Currently shuobject emulates subset of the SWFObject library. One question is still opened: shall everything be in single file. Pros: will not require iframes and web server to execute; cons: will require major refactoring to not pollute the global scope and total size of the embedded abc code will grow by 25%.
Marking this fixed: shuobject works quite well and we should track specific improvements in separate bugs.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.