Hi Carlos,
On first and second and third glance there seems to be a couple of ways to
go about this.
1. Replace Flash Display List with Starling Display List at compile time.
We would create an alternative set of classes that had the same method and
property signature as DisplayObjects and DisplayObjectContainers. Any
instances where flash.display.DisplayObject was declared would have to be
replaced by starling.display.DisplayObject. This could be done in the
compiler and set with a flag.
This may be a lot of work or a 80 / 20 type of thing. Where 80% is free off
the bat and we spend much more time getting the remaining 20%. It depends
on how much Starling matches API wise. A simple DisplayTree test such as Om
suggested would give an initial idea of the amount of work.
The cons are that it would require compiler work and the classes to match
1:1. Although, we may be able to do a search and replace of the SWF after
the fact rather than at compile time. Jangeroo may be doing something like
this for replicating drawing calls on the JavaScript side.
2. Create an abstraction layer for rendering. At startup register the class
you want to use for rendering in the SingletonManager. All visual calls
would go through that at their last step. The pros are a hot swappable
rendering layer and possibly little to no compiler work. This would require
tens of thousands of lines of code changes and may introduce complexity in
testing and debugging.
3. Add in a flag at native display list junction points to proxy drawing to
the Starling DisplayList. All display objects are added by addChild call.
So in the root base class right before native call we check for a preferred
rendering target.
/**
* @private
* This method allows access to the Player's native implementation
* of addChild(), which can be useful since components
* can override addChild() and thereby hide the native implementation.
* Note that this "base method" is final and cannot be overridden,
* so you can count on it to reflect what is happening at the player
level.
*/
mx_internal final function $addChild(child:DisplayObject):DisplayObject
{
return FlexGlobals.toStarling ? FlexGlobals.starling.addChild(this,
child) : super.addChild(child);
}
The cons to this are many including possibly duplicate display list,
dispatching events, etc. The graphics calls would also have to be patched
and have to be done in skins and it's unclear how to handle FXG etc. This
would be more of a test than a long term solution but would have smaller
bite size steps and immediate results. I also bring up this option because,
for me, in big projects like this the ability to see small incremental
results usually inspires me to continue it to the next step.
My two cents
On Wed, Jul 10, 2013 at 11:38 AM, Carlos Rovira <carlosrov...@apache.org>wrote:
> Hi,
>
> from time to time people comes with the desire to see Flex running on
> Stage3D. I would want to recopile all the state of the art info about this
> topic and see if is possible and how much work it would require.
>
> I know people like J.Campos did two attempts and get valious research from
> that experience. There's things to get into account like accessibility.
>
> Please could people share in this thread the things they know in order to
> recopile all info? Is there some things to take into account that could
> make Stage3D not possible for Flex? Could we overpass it and make it
> possible? If it would be possible...it will brings real benefits?
>
> If some work is done in this topic, I'd propose to make focused in this
> particular thing and unlike FlexJS, here I will not try to break
> UIComponent in small parts, or break compatibility. Even if it could be
> possible to have a global flag like "enableStage3D" to make our apps run on
> Stage3D if is true or remain in normal display layer, it could be great.
>
> Thanks in advance for any insight regarding this topic.
>
> Best
>
> Carlos
>
