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
example).
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, imagene...@gmail.com 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.
