incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sébastien Paturel <>
Subject Re: Changing Flex rendering to abstract renderer
Date Sat, 24 Mar 2012 12:02:29 GMT
Great initiative !
I also believe that flex has a great future if we manage to get it cross 
compiled to HTML5 and maybe other platforms (video game platforms for 
The future is mutli screen (smart tv coming) and media merging in one 
device (phone, computer, watch, videogame etc in one device), the 
ability to target all platforms easily with cost effective solution is gold.
consistency and ubiquity is what made flash a great success, and is what 
give flex a big potential.
And i also believe thats its doable.
Lets stop thinking of flash only with flash player, its a flash platform 
we're talking about, not only a runtime! tools and framework will be 
more relevant then ever in such a near future.

The fact is that cross compilation and languages is not the hard part.
Falcon and what has been done with Falcon JS already gives the solution.
The hard part is to run on HTML5 (for example) what flash player run for us.

FlasconJs is trying to run on HTML5 stack.
But trying to run on GPU is easier solution i think.
Nowadays, every new hardware (smart screen) rely on a powerfull GPU.
GPU performances and power consumption efficiency is growing much more 
quickly than CPU.
And by chance, the GPU apis and implementations are more standard than 
HTML5 for example.
Getting flex run on GPU is giving better performances and open the gate 
to run mostly on any device.

If we get flex cross compiled to JS, Java and C++, and run it on GPU 
threw OpenGL ES (WebGL) api for example, targeting any new device would 
become straight forward.
we get better performances, less battery consumption, eeasy to target 
new devices...

i dont know if its what you have in mind with your initiative, but it is 
definitly a great way to take flex ubiquitus.

Le 24/03/2012 11:41, a écrit :
> I am porting Flex to Starling with a fork of Starling that will have the
> additional functionality to support such a port. Besides that, I will
> attempt to get Flex working with Jangaroo. I have not looked into Jangaroo.
> To facilitate both targets, I will be switching references to
> flash.display.Sprite and other necessary classes for the subset of Flex
> that I'm starting with (Spark), to a class that implements the necessary
> interfaces for Flex.
> As there are no short term goals of switching the native DisplayList API to
> render with Stage3D, and it's likely that short term developements in
> Actionscript to Javascript compilers (haxe, nme) will continue to work off
> native display list API, I think its a good idea to transition Flex to an
> interface base rendering solution to target Stage3D and the native display
> list. I hope that Jangaroo provides or the the Flash community settle on an
> abstract rendering API to target both Javascript and Stage3D.
> I will post my benchmarks with the graphics object rendering to bitmaps and
> then to Stage3d as soon as I have them.
> To be honest however, I will most likely not use interfaces to cut down on
> development and as its not really necessary as Starling is close enough,
> but will simply have the Flex referenced classes extend Sprite from
> Starling and native Sprite depending on the target.
> Anyway, fundamentally for the greater Flex community, getting Flex to run
> on Javascript is absolutely critical and will make Flex be the number #1
> Javascript framework by far.

View raw message