incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Williams Farias <will.far...@gmail.com>
Subject Re: Changing Flex rendering to abstract renderer
Date Sat, 24 Mar 2012 13:17:21 GMT
+1 !! Hey, thats bizarre! I havent even know about Satrling and Jangaroo!
But yes, thats EXACTLY the point to Flex get over everything on the web!
Develop in Flex, run in HTML Canvas! Insane!

2012/3/24 sébastien Paturel <sebpatu.flex@gmail.com>

> 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, imagenesis@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.
>>
>>
>

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