On 10/19/16, 8:35 AM, "Josh Tynjala" <joshtynj...@gmail.com> wrote:
>"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."
>
>I was already leaning toward agreeing with Harbs, and this argument only
>cements it more strongly for me.
The only reason HTML objects are wrapped is because I don't know of any
other way to create a subclassing model that MXML uses. IOW, if you could
extend HTMLButtonElement and instantiate it via "new
MyHTMLButtonElement()" the JS side would not have HTMLElementWrapper at
all. I considered __proto__ hacking, but ruled it out. I could certainly
be wrong, but I would be surprised if whatever new hot platform we want to
target someday doesn't have an object-oriented extension API.
I've watched as document.createEvent("MouseEvents") has been deprecated in
favor of "new MouseEvent()". If the browsers ever did the same for
document.createElement, I would want to unwrap the JS code. The wrapping
was not done to present a cleaner API to developers. I would want the
tools to present the cleaner API, but let the implementation be as optimal
as possible.
That is, however, hard to do today, especially for the SWF version, since
the verifier doesn't allow subclass overrides. So maybe we will just have
to live with wrapping both JS and SWF sides for now, but I'd like to
explore having the tools allow subclass overrides before we give up. For
the SWF implementation, wrapping potentially means that we can't leverage
the runtime's event model and have to build out our own.
-Alex
>
>- Josh
>
>On Wed, Oct 19, 2016 at 2:16 AM, Harbs <harbs.li...@gmail.com> wrote:
>
>> 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
>>
>>
