incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesus Barquin <yuka...@gmail.com>
Subject Re: Changing Flex rendering to abstract renderer
Date Sat, 24 Mar 2012 11:45:17 GMT
+1

2012/3/24 Paw Suddergaard <paw.suddergaard@gmail.com>

> 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