[ASJS] Apache Flex and JooFlash

[Frank Wienberg <fr...@jangaroo.net>]

With ASJS/FalconJS and FalconJx, we have different approaches to generate
JavaScript from ActionScript to make Flex applications run directly in any
browser. If I am not mistaken, we do not yet have the Flash core library
available (DisplayList etc.). Bernd Paradies, the original author of
FalconJS, called this FlashRT, but as far as I know, it has not (yet?) been
donated to Apache.
As part of the Jangaroo project, I wrote a tool to "screen-scrape" Adobe's
HTML documentation of the Flash API (it has a creative commons license) and
convert it to ActionScript API. I started implementing this API in
ActionScript, using canvas to render in the browser. On the Jangaroo web
site, there are several examples of AS applications that, without changes
to their source code, now run in the browser without a Flash plugin:
http://www.jangaroo.net/applications
JooFlash is part of "jangaroo-libs" which has an Apache 2 license and is on
Github here:
https://github.com/CoreMedia/jangaroo-libs

The Flash API is really huge, but I guess I implemented most of what is
typically used in Flash applications.

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?

-Frank- J8)

Re: [ASJS] Apache Flex and JooFlash

[Frank Wienberg <fr...@jangaroo.net>]

On Tue, Jan 22, 2013 at 6:30 PM, Alex Harui <ah...@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)

Re: [ASJS] Apache Flex and JooFlash

[Alex Harui <ah...@adobe.com>]

On 1/22/13 4:30 AM, "Frank Wienberg" <fr...@jangaroo.net> wrote:

> With ASJS/FalconJS and FalconJx, we have different approaches to generate
> JavaScript from ActionScript to make Flex applications run directly in any
> browser. If I am not mistaken, we do not yet have the Flash core library
> available (DisplayList etc.). Bernd Paradies, the original author of
> FalconJS, called this FlashRT, but as far as I know, it has not (yet?) been
> donated to Apache.
The FlashPlayer emulation in JS is not being donated.  Only the FalconJS
code that we have.

> 
> 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.

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.

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui