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.far...@gmail.com> wrote:
> Hey > imagene...@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 <aha...@adobe.com> > > > > > > > > > On 3/24/12 3:41 AM, "imagene...@gmail.com" <imagene...@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 > > > > >