One thing you need to worry about when using starling is that the
eventdispatcher api is different. Starling does not allow 'weakl
isteners' or more accurately, only allows them. Meaning the method
signature is different.
On 11 Jul 2013 18:27, "Carlos Rovira" <carlos.rov...@codeoscopic.com> wrote:
> 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
>
