flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: [FlexJS] HTMLElementWrapper extending Sprite
Date Fri, 21 Oct 2016 19:12:48 GMT


On 10/21/16, 3:26 AM, "Harbs" <harbs.lists@gmail.com> wrote:

>Let’s see if I can do a better job at explaining myself.
>
>> Seems like that would just stomp on the current basic set.
>
>Yes. And I think that’s appropriate for now.
>
>When I say default, I mean that we should have one set of components that
>we’re all working on for now. We all have limited time, and splitting our
>time over two component sets is going to add significant overhead.
>Migrating the port to a new component set seem like a big job and will
>take time I do not have. Also, telling new users which component set to
>use is going to add extra friction to adapting the framework.

Carlos is working on an MDL set.  We want to make sure FlexJS can handle
more than one set.  We don't have to all work on one set.

>
>AFAIK, the only performance overhead in wrapping Flash components is an
>extra getter/setter call. I don’t see how there would be any extra memory
>overhead. 

Instead of creating a new Sprite, you are creating a new Sprite and
another object to wrap it.  This is worrisome in the sense that, for every
person who is struggling to get a certain update rate in their app,
wrapping essentially means there are twice as many objects to be updated
in the same amount of time, although the update time of the wrapper may
not be the same as the update time of the inner widget.  Twice as many
objects is twice as much work for the Garbage Collector.  It is more lines
to step through when debugging.  If we told potential FlexJS customers to
wrap all of their code in another layer in order to use FlexJS I think we
would have fewer customers.

>
>Now, back to the problem of not wrapping Sprite:
>
>Yes. The case I mentioned is a much bigger problem in migrated code than
>new code (and in new code there’s still the issue of undocumented
>reserved properties when targeting Flash), but it’s not the only issue.
>It’s been a while, and I don’t remember all the nuances of the issues we
>encountered. Maybe Yishay remembers more.
>
>We encountered numerous issues related to events. Some of the problems
>were related to the fact that event bubbling is different in Flash than
>it is in JS. Some of the problems were due to the fact that the events
>were dispatched by the Flash objects — those issues were at least
>partially due to the fact that Flex MouseEvent does not subclass the Flex
>Event. I don’t see any way of fixing that other than wrapping Sprite. I
>think we need to make events identical across platforms.
>
>There are possibly issues I’m not remembering now, and there’s possibly
>other issues we did not run into.
>
>Again: My objection is that I believe the idea of having
>platform-specific implementation details leaking through is fundamentally
>wrong and should be avoided if at all possible.

I guess I don't understand why it is wrong.  IMO, you were the first
pioneer and I'm really thankful that you took the risk to do so.  In US
history, the pioneers had a covered wagon pulled by an ox.  There were no
paved roads.  Some days, they were only able to go one mile!.  You found
that by taking an extra mattress and sitting on it, it made the ride more
bearable.  However, the tool chain is slowly coming behind you paving
those roads.  I think I will be able to fill in every bump in the road you
went over.  If there is something I can't fill in, I would like to
identify what that is, because that would definitely make me change my
opinion.  IMO, folks just aren't going to need an extra mattress.  You can
argue that the ox is so strong that it doesn't matter, but if you do try
to drive off-road and get stuck in the mud or there are other things you
would much rather pack into your wagon, you will want to leave that
mattress behind.  Just this week there is a thread about mobile
performance.

Now from my experience with Flex, I saw some things happen.  Flex's job
was to put a layer over Flash and essentially hide all the Flash-isms,
especially frames, and make an API that was more "programmer-oriented".
You were supposed to use SystemManager instead of Stage, for example.  But
when I peek at other people's apps, I see a lot of use of Flash APIs
anyway.  Why?  Because they needed to get down to the lower-level for
optimization.  And then, folks started creating other lightweight
frameworks as alternatives to Flex.  I also saw the argument that my
change only causes 10ms delay.  I after seeing it 100 times, we had a full
second delay and nobody could point to what to remove to try to get it
back to something ignorable.

Also note: the reason MouseEvent doesn't extend Event doesn't have
anything to do with wrapping Sprite or not.  And any inconsistencies
between the JS and SWF event model simply need to be resolved.  I think
resolving it so the unwrapped set matches the JS side will lots easier
than writing a whole new event model for wrapped Sprites.

>
>We have a conflict between ideals here. You want a the highest possible
>performance under all circumstances, and I want the highest level of
>compatibility across platforms under all circumstances.

I think the tool chain can get you that compatibility so there is no
conflict.  I'm still wondering what the killer scenario is that the tool
chain cannot solve.  I am open to the idea that there is one.

>These two ideals are at head with each other here, and we’re going to
>have to decide which one is more important. I think I’ve made opinion
>clear on that question. The performance issue is a theoretical one which
>I don’t believe will have practical implications, while the compatibility
>one is a practical one which already bit me. Trying to maintain two
>complete component sets at this point I believe to be counterproductive
>and I don’t believe it will resolve performance issues that might arise
>anyway. If we identify use cases where performance is an issue, I would
>suggest specific components designed for those use cases (and not a whole
>new set).

I would like to work on one Basic set too, but your set doesn't sound like
it is Basic.  It sounds like it is aggregating APIs into the component
surface to simplify migration.  And that's fine with me.  I would love to
have a component set tuned towards migration.  I just would caution about
using your experience with a new tool chain to make decisions that we will
carry around for a long time.

Maybe the answer is that I copy the current unwrapped Basic set to new
SWCs, then you can drop the wrapped set on top.  Then I will work on the
tool chain to see if we can resolve all of your issues without wrapping.

-Alex

Mime
View raw message