incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paw Suddergaard <paw.sudderga...@gmail.com>
Subject Re: Changing Flex rendering to abstract renderer
Date Sat, 24 Mar 2012 11:01:01 GMT
That is an awesome initiative!

Do you have a blog/twitter/xx where its possible to follow your work?

/paw

On Sat, Mar 24, 2012 at 11:41 AM, imagenesis@gmail.com <imagenesis@gmail.com
> wrote:

> 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