Hi,
many thanks to all responses. Very useful info, thoughts and discussion.
As we learn and think about new enhancements and evolutions of the actual
flex sdk, more difficult is to get viable solutions that make it backwards
compatible with the existing codebase of flex projects. I'd like the idea
of actual SDK going Stage3D but I think we would end with a frankenstein
that breaks compatibility and that will defeat the effort.
For what you guys sugest here, it seems that the best place to try to get
Stage3D support is in FlexJS. So we could try to introduce Starling here
and setup the initial bricks and see how far we reach, due to the fact that
FlexJS SWF version is already very basic, and hope that the projects that
Om mentioned would come by the way at some time in the future.
This will make FlexJS even more desirable since we well get HTML output and
SWF GPU.
I'll make more research about this topic in the following weeks as time
permits and will report if I get something valuable.
2013/7/10 jude <flexcapaci...@gmail.com>
> 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
> >
>
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 94 80 80
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es
