incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Campos <jonbcam...@gmail.com>
Subject Re: Changing Flex rendering to abstract renderer
Date Sun, 15 Jul 2012 18:16:40 GMT
After looking at the issue and getting some basic stuff working I can say
that it will take a pretty significant code split to make work. This would
be something best planned into a flex 5 development.
On Jul 15, 2012 3:32 AM, "Williams Farias" <will.farias@gmail.com> wrote:

> Hey
> imagenesis@gmail.com,
>
> 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?
>
> Thanks.
>
> 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
> >
> >
>

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