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 Sun, 15 Jul 2012 08:31:28 GMT

Do you have any news about that technologies? Jagaroo, Stage3D and your
experiments on that?

Do you have a website, blog or other way to receive news on that?


2012/3/25 Alex Harui <aharui@adobe.com>

> On 3/24/12 3: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.
> It would be my strong preference that you first try to become a committer
> for Apache Flex by submitting some patches for some bugs, enhancements or
> new components, then work on this port as a member of Apache Flex.  First,
> it will allow us to help make sure that you don't do anything that Apache
> Flex cannot use, like forking some other project like Starling without
> permission or using code with an incompatible license, and it will allow
> folks on this list to discuss trade-offs you may choose to make like the
> decision about interfaces before you go so far that your port becomes
> unacceptable to the folks on this project.  And it will allows others to
> participate in an Apache-compatible way and hopefully go faster.
> This idea has been brought up in the early days of this podling. The main
> concern I have is the accessibility story.  There isn't a good one at this
> time and that is critical to many enterprises and governments.  But it
> doesn't mean that a clever solution cannot be created.
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui

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