incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: Changing Flex rendering to abstract renderer
Date Sun, 25 Mar 2012 05:02:35 GMT



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
View raw message