On 10/18/16, 10:26 AM, "Harbs" <harbs.li...@gmail.com> wrote:
> >On Oct 18, 2016, at 7:30 PM, Alex Harui <aha...@adobe.com> wrote: > >> >> >>OK, I think you are describing a different problem. AIUI, you are saying >> that certain APIs cannot currently be overridden or overloaded to take a >> subclass or alternate type. That you can't override Sprite.transform to >> take a org.apache.flexjs.Transform. I could look into getting the >> compiler to accept overrides/overloads. I thought I'd done some of that >> already. > >This is the main problem I was having. It’s not just “overriding”. The >HTML side of things do not have the properties defined at all. The Flash >ones have the properties, and they are used in a possibly different way >than you would use them. Events are a problem that’s somewhat related to >this, but not exactly. Basically, Flash is limiting how we can implement >things for HTML output, and I think that’s a bad thing. The decision on whether to wrap or not will impact how we implement events. Yes, we are putting an emphasis on HTML output and its size and performance and are willing to make some sacrifices on the SWF size and performance, but as I mentioned recently in another thread, we do want to leave the door open to a third platform some day. That means to me that we really want to enable building a framework that targets multiple platforms in as low a level as we can, and use the tooling to show folks the common APIs they should use, and the conflicts against the platform-specific implementations. The alternative, which is to always seek abstractions that have more commonality, is a viable direction, but I think we are here because the overhead of doing so was prohibitive to creating small fast apps. Also, looking down the road, the recent discussion about language features implies that we will need to implement some type of overloading. So, I would like to understand where the really painful places are where Flash is getting in the way and see if starting down the path of supporting overloading will get us around it. You mentioned Sprite.transform. Can you provide more detail on that scenario? I think Sprite.parent may be one. And I think there were some issues are Rectangle and Point as well? > > >> >>> >>>> Animations pound on x,y,width,height as does layout. >>> >>> So what? If there’s a specific case which is performant sensitive, the >>> Flash implementation can manipulate the underlying Flash objects >>>directly. >>> >>> I really believe that composition is the better solution >>>architecturally >>> (as it’s doing for the HTML side). I’d like to see some proof that >>> there’s a memory usage issue with using composition, and I believe >>> performance issue which might come up can be dealt with (by using SWF >>> code blocks and addressing the $displayObject properties directly). >> >> What would be the pattern for optimization? Without tail-optimization, >>I >> don't see how you can reduce function calls. IOW, when I set >> Button.width, it will set element.width. How do you get Button.width to >> directly set the Sprite's width in a COMPILE::SWF block? > >The underlying DisplayObjects are available for direct access in a SWF >block. I expect most code which would need optimization to be in >Framework code, so instead of calling Button.width, you’d call >Button.$displayObject.width. Currently, $displayObject is a getter, but >if that proves to be a performance problem, it could easily be converted >to a simple property. > >Yes, you have an extra property reference (i.e. $displayObject), but I >find it hard to believe that’s going to be an issue. Even if it is (i.e. >in a tight loop), the DisplayObject reference can likely be cached. > >Does this sound reasonable? IMO, we want the entire framework to have as few SWF-specific code paths as possible. Lots of layouts and effects can be written without conditional compilation and thus the optimization you suggest wouldn't be available. Thanks, -Alex
