You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While I understand and agree with this project's perspective of keeping Flash/Shockwave alive by preserving it in the open, for historical/archival purposes, I believe there could also be some compelling technical reasons for wanting this technology. Admittedly, I've only been investigating this fairly recently, but in my efforts, this article cropped up:
In here, the author performs a series of benchmarks comparing an LLVM backend of an existing open-source Flash implementation, Tamarin, to the NanoJIT implementation of the Actionscript ByteCode (ABC) backend. The results are quite interesting, with many cases of the NanoJIT actually managing to pull ahead in some regards!
The Flash technologies were engineered from the ground-up to provide a small-footprint, fast-interpreted multimedia technology for the web. These goals are clearly aligned with those of the WebAssembly project in attempting to foster a universal bytecode. I believe a proper comparison of WASM and ABC is in order, as perhaps there are some areas where Adobe has gathered implementation knowledge in overcoming certain obstacles that the WebAssembly team has not yet considered.
This, to me, forms one of the most compelling reasons to open Flash as much as possible - specifically any patents still pertaining to technologies such as the NanoJIT. If ABC could stand as the complete bytecode implementation to be integrated in the same space as WASM, with some technology such as Mozilla's Shumway making a comeback to convert the remaining elements in an SWF file to HTML5/CSS3 objects, plugin-less full-browser integration of Flash could become a real possibility. Archival teams would then merely have to work to convert older-format files to the latest versions, so the attack surface, and undefined behavior for such an implementation would not be anywhere near as great as current implementations of the Player.
What are your guys' thoughts? I'm honestly really excited to dive in and take a look at all of this!
The text was updated successfully, but these errors were encountered:
While I understand and agree with this project's perspective of keeping Flash/Shockwave alive by preserving it in the open, for historical/archival purposes, I believe there could also be some compelling technical reasons for wanting this technology. Admittedly, I've only been investigating this fairly recently, but in my efforts, this article cropped up:
http://www.masonchang.com/blog/2010/11/10/tamarin-on-llvm.html
In here, the author performs a series of benchmarks comparing an LLVM backend of an existing open-source Flash implementation, Tamarin, to the NanoJIT implementation of the Actionscript ByteCode (ABC) backend. The results are quite interesting, with many cases of the NanoJIT actually managing to pull ahead in some regards!
The Flash technologies were engineered from the ground-up to provide a small-footprint, fast-interpreted multimedia technology for the web. These goals are clearly aligned with those of the WebAssembly project in attempting to foster a universal bytecode. I believe a proper comparison of WASM and ABC is in order, as perhaps there are some areas where Adobe has gathered implementation knowledge in overcoming certain obstacles that the WebAssembly team has not yet considered.
This, to me, forms one of the most compelling reasons to open Flash as much as possible - specifically any patents still pertaining to technologies such as the NanoJIT. If ABC could stand as the complete bytecode implementation to be integrated in the same space as WASM, with some technology such as Mozilla's Shumway making a comeback to convert the remaining elements in an SWF file to HTML5/CSS3 objects, plugin-less full-browser integration of Flash could become a real possibility. Archival teams would then merely have to work to convert older-format files to the latest versions, so the attack surface, and undefined behavior for such an implementation would not be anywhere near as great as current implementations of the Player.
What are your guys' thoughts? I'm honestly really excited to dive in and take a look at all of this!
The text was updated successfully, but these errors were encountered: