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
>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
>>> I really believe that composition is the better solution
>>> (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,
>> 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