Despite the fact that we’re putting an emphasis on HTML performance, HTML objects are wrapped. (I think it’s a completely reasonable approach for HTML.) This causes none of the HTML APIs to leak through. The same should apply to Flash objects and any other future platforms we might have in the future. If there’s cases where this causes performance problems, I think it can be dealt with in a case-by-case basis.
I think it would be great to show conflicts against platform-specific implementations, but I think we should keep those to a minimum. I don’t remember all the conflicts we had. Warnings would have helped somewhat but not totally. Here’s one example (of many): We were using a Sprite Image component, and we needed to migrate to a FlexJS BinaryImage component. Some of the properties we were using were: scaleMode, smooth, cacheAsBitmap, blendMode, filters, mask, rotation, scaleX, scaleY The neatest way to migrate our code was to create a subclass of BinaryImage which implements all (or rather most of) these properties and use transformation, clipping, etc. beads to implement the functionality. This allows all the code in our app which uses the original Spark components to remain the same. Inheriting from DisplayObject (and children) would make using the same properties impossible because these properties are already used in Flash. On Oct 18, 2016, at 8:52 PM, Alex Harui <aha...@adobe.com> wrote: > > > 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
