incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jude <flexcapaci...@gmail.com>
Subject Re: Cross-compiling Flex to HTML5/Javascript (Was : Update on Falcon donation)
Date Thu, 30 Aug 2012 20:36:33 GMT
One thing that keeps coming back to me on this conversation is the argument
of performance, time to market and bandwidth vs correct architecture.

Why are we targeting HTML? Apple decides not to support Flash in iOS so now
Adobe rearranges resources to develop HTML development tools so now we are
talking about having Flex export to HTML.

Yes, Flash Player uses 3rd party tools, so why not compile those to
separate libraries (if they're not already) and then open source the rest?
Not open in an Android way.

To *guarantee* we get the same results across browsers we need to use
something like the drawing canvas or SVG (or drawing commands) such as
Flash uses itself REGARDLESS of performance. If we depend on browser
manufacturers for different feature sets or API's we will be waiting a long
time. Architecture IMHO is more important than speed because in time CPU
and GPU performance will increase, in time bandwidth will increase and
software performance will increase.

Remember when iOS 5 came out a year or so ago? The HTML5 performance in
that browser was 2FPS. After that update it was 35-40FPS. A 2000% increase.
[1]

And this project (export to HTML) will take time. So when it's usable two
to three years (?) from now how will the environment change?

PS Jangaroo cross compiles AS classes and packages to JS. [2]

[1] http://www.guypo.com/mobile/ios5-top10-performance-changes/
[2] http://www.jangaroo.net/home/



On Thu, Aug 30, 2012 at 12:37 PM, Michael A. Labriola <
labriola@digitalprimates.net> wrote:

> >I haven't seen FalconJS but from what I read, it looks like it plays with
> the DOM.
>
> FalconJOS (at least the Flex demo) basically tried to make a big SVG which
> was rendered by the browser for interaction. Less than ideal on a few
> thousand levels
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message