Firing run loop on mousemove unnecessary?

[asakusuma]

Looks like a new run loop is kicked off every time the mouse moves.

Is this really necessary? @stefanpenner suggested that we might instead have components opt-in to needing this, instead of assuming we need a run loop on mouse movement.

[stefanpenner]

It's only happening just in-case someone has a mouse related handler on one of the rendered components. If instead components informed the event dispatcher the events they need on render and no longer need on un render. We could remove this, instead only listening to exactly what is required.

The mouse/touch events introduce an unfortunate cost, especially when they are not frequently used.

[asakusuma]

Is there a way to infer this from the component, or would the component need to manually declare what is needs?

If the latter, we'd need to choose the set of events that are listened for by default, and the set of events you need to manually opt in to.

[stefanpenner]

Is there a way to infer this from the component

yes, https://github.com/emberjs/ember.js/blob/master/packages/ember-views/lib/views/component.js#L223 is how one declares interest in an event from a component.

[asakusuma]

So then we could just ref count this on component creation and the decrement on destruction, and then add and remove this listener as needed?

[chadhietala]

I think this gets tricky with improved actions, because you can declare event handlers in the template.

<input onmouseover={{action 'reasonable/unreasonable'}} />

You completely loose the ability to introspect the class.

[rwjblue]

@chadhietala - In that scenario, you are not actually using the EventDispatcher (or Ember event bubbling at all), you are registering a custom onmouseover handler.

[chadhietala]

@rwjblue So it doesn't cause a runloop? Is this the same for the old on= syntax as well?

[rwjblue]

@chadhietala - No, {{action "foo" on="mouseover"}} would definitely go through EventDispatcher, and would have the issue you are cautioning against if we didn't take it into account.

[stefanpenner]

Yup it causes a run loop, but it's one that you want. Since you are absolutely invoking ember code. This is much better then all the preemptive handlers that run for. All mouse events regardless of if a handler is present.

An interim step is actually to skip the run loop for events that don't find a handler.

[stefanpenner]

https://github.com/emberjs/ember.js/blob/master/packages/ember-views/lib/system/event_dispatcher.js#L234-L242 could likely detect if the given view has such a handler, and only invoke the run-loop if it is about to enter user code.

To handle bubbling correctly, it may need to be slightly more creative.

This approach I believe will be the easiest, no ref counting needed. Sure we sill need to attach event listeners to everything, but we only bother invoking a run-loop if we truely are about to invoke code that requires it.

I suspect this will cure the original concern which prompted this issue.

[asakusuma]

So to make sure I understand this, the idea is to:

• Check the immediate view to see if actually has a handler for the given event
• If handler present, proceed
• If not, repeat on parent, if no parent, no-op

This sounds like it will address my issue. However, what is more expensive, traversing the view hierarchy looking for handlers, or executing a no-op run loop?

[stefanpenner]

We traverse it anyways

[runspired]

The mouse/touch events introduce an unfortunate cost, especially when they are not frequently used.

jQuery fast paths event handling for many events, I think Ember should likely look into doing so too, in addition to any inquiry into using useCapture for events. Therese a huge perf win being able to delegate directly instead of bubbling, and the current implementation not only needs to bubble, but needs to run multiple checks at each view/component layer for handlers.

I'd put the overall cost on this as an extra .5-4ms / touchmove or mousemove event that's being used to manipulate position on screen (much of which depends on how many layers it needs to bubble through etc.). Not horrendous, but definitely expensive when lots of such events are involved.

(Edit: that cost I peg above is a rough eyeball of the difference between using touchmove through Ember and using it as a direct handler on the component)

[stefanpenner]

I believe we are limited by our ie9 support and a true bubbling phase. Maybe not?

Would love for someone to dive into this area an propose some improvements. Enumerating cost/benefit would also be handy

[runspired]

IE9 allows for useCapture, IE8 support doesn't.