On Tue, Jan 22, 2013 at 6:30 PM, Alex Harui <aha...@adobe.com> wrote:
> > If you'd be interested, I'd contribute JooFlash to FalconJx (or FalconJs; > > should not really make a difference, as it is ActionScript code). My > > employer CoreMedia signed a CCLA, so there shouldn't be a legal problem. > > > > What do you think? > We would need to make sure there aren't any legal issues with trying to > write different implementations behind the Flash Player APIs. But > otherwise, I certainly would accept such a donation. > Please go ahead. I did not have access to any of the FlashPlayer sources, nor did I try to decompile any binaries. The only (re)sources I used to implement the Flash API are: - Adobe's online documentation<http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/index.html>(creative commons) - LightSpark <http://lightspark.github.com/> (LGPLv3) - DartFlash <http://www.dartflash.com/> (Simplified BSD) - Blog post on flash.geom.Matrix<http://www.senocular.com/flash/tutorials/transformmatrix/> > > To be clear, my vision of the framework I'm working is to not rely on Flash > Player emulation for success. Again, it is about performance and > expectation management. Once you say you are going to implement Flash in > JS, folks will be disappointed to find you've only done a subset, or there > are corner cases that don't work well. Then you are under pressure for the > rest and that might end up taking a lot of time and it may not perform as > well. On the other hand, if you say, "hey, we have limited vector graphics > support that uses some of APIs that should look familiar to you", folks > will > have lower expectations. I can certainly see adding vector graphics > support > to the framework I'm working on over time. It could initially be limited: > you might have to place a particular component in your UI to draw on it. > You may not be able to draw over, around and under everything like you can > in Flash today. If it turns out that the code you donate can be repurposed > for that, great. > I see your point. We have to manage expectations. But on the other hand, why give developers a "same same but different" API for the parts of Flash that can be emulated in HTML5? I took various ActionScript applications and tried to run them, and implemented all the Flash API needed until they worked. I never had to change a single line in the application source code. (Well, to be honest, I had to, but that was because of shortcomings of the Jangaroo compiler, which Falcon won't have.) Another argument is that the Flash API already comes in different flavors for different FlashPlayer versions, AIR, and mobile AIR. Thus, people are used to not everything being supported everywhere. The part of JooFlash that actually renders is quite easy to implement differently, as I noticed when moving from DOM-rendering (every DisplayList object has its own DOM element) to rendering a complete DL subtrees to a single canvas if the "cacheAsBitmap" flag is set. However, it could still do with some refactoring. So in short, yes, I think my code can be "repurposed", and I still think we cannot publish Flex / JS without support for at least a subset of the Flash API. -Frank- J8)
