Throttle mousemove internally

[mourner]

Ref #2334. I’ve lost count of times where I gave advice to throttle mousemove whenever someone had performance issues with interactivity. I think mousemove should be throttled internally by default — it always helps with performance, and I can’t think of any drawbacks/gotchas in this particular throttling case.

This, coupled with the preventDefault fix in the example, makes the point dragging example much smoother. After we fix setPaintProperty triggering cascade, it’ll become butter-smooth.

cc @lucaswoj @jfirebaugh @ansis @tristen

[ansis]

Are there any cases where a user would want unthrottled events?

Does this solve the problems or just make them less severe? Could the work triggered by the events still cause backups?

Would it be better to throttle the actual work instead of the events that trigger the work? (should setData queue up new data if work is still in progress?)

If we throttle, we should throttle with requestAnimationFrame instead of setTimeout 16ms.

• frames might take more than 16ms
• chrome aggressively de-prioritizes setTimeout in some cases: sources are never updated while zooming #2139 https://code.google.com/p/chromium/issues/detail?id=567800

[mourner]

Are there any cases where a user would want unthrottled events?

I can't think of any, but let's see if anyone can.

Does this solve the problems or just make them less severe? Could the work triggered by the events still cause backups?

It's a part of the solution, which is "avoiding unnecessary work". It can't solve all the problems but it always improves performance in case expensive mousemove handlers.

Would it be better to throttle the actual work instead of the events that trigger the work? (should setData queue up new data if work is still in progress?)

I don't think so, because throttling the actual work can have unexpected side effects and introduce subtle bugs. But specifically in case of mouse events, I can't think of a case where it would cause problems.

If we throttle, we should throttle with requestAnimationFrame instead of setTimeout 16ms.

Agreed. Should we modify util.throttle to automatically use reqAnimFrame when time is 16ms or less, or should we do a separate util method in util/browser/browser.js?

[lucaswoj]

This looks great!

👍 to a separate frameThrottle util method in util/browser/browser.js.

[mcwhittemore]

Won't this break stopPropagation?

[jfirebaugh]

Yes, and preventDefault.

I'm 👎 here. We've seen several instances where internal throttling in Leaflet caused issues and had to remove it. It just generally seems to be a bad idea to do it at the library level.

[mourner]

But you're strongly against exposing util methods like throttle in public too. And we can't use third-party utility libraries in our examples. What should we do here then? I'd really like to make our examples fast.