Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pointer event performance #11

Closed
forresto opened this issue Oct 15, 2013 · 9 comments
Closed

pointer event performance #11

forresto opened this issue Oct 15, 2013 · 9 comments
Labels

Comments

@forresto
Copy link
Collaborator

I'm noticing that moving nodes is pretty slow, and I think the timeline is saying it is the pointer event polyfill's fault.

screen shot 2013-10-15 at 10 00 02 pm

Found another polyfill that could be worth trying: https://github.com/Rich-Harris/Points

Since that one intercepts events at the window level, it could maybe allow gmaps-like panning while dragged outside of the window.

@bergie
Copy link
Member

bergie commented Oct 16, 2013

I wouldn't start performance tuning this part quite yet, and in any case part of it might be the fact that we have multiple gesture recognizers running on the same element (one for each the-behavior).

Node moving will feel quite different when we start snapping them to grid, as well.

@bergie
Copy link
Member

bergie commented Oct 16, 2013

See also jquery-archive/PEP#92

@dfreedm
Copy link

dfreedm commented Oct 16, 2013

Feel free to file a performance bug if you determine that this is in PointerEvents.
FWIW, I refactored some low hanging fruit recently (jquery-archive/PEP#102) and only just now pushed it to bower.

@bergie
Copy link
Member

bergie commented Oct 18, 2013

Regarding multiple gesture recognizers, things should be a lot more efficient when we have get the-grid/the-behavior#2

@forresto
Copy link
Collaborator Author

Seems a little better with the-behaviors, but still <30hz. Wondering why we're getting more than one mousemove event per frame, and why they are so expensive. Does it make sense that we are doing more mousemove calculations than screen updates?
screen shot 2013-10-19 at 8 05 44 am

@bergie
Copy link
Member

bergie commented Oct 21, 2013

One reason can be that we're currently setting a drag="x y" attribute to
the node being dragged.

This causes the dragChanged method to be called on the web component. But
since the attribute change notifications are asynchronous in Polymer, this
could be a reason why we miss moves.

@forresto
Copy link
Collaborator Author

Tried using https://github.com/Polymer/PointerGestures instead of the-behavior. Seemed like a big improvement. On mobile, panning went from 140ms to 60ms.

Test in new branch: https://github.com/the-grid/the-graph/tree/pointergestures

noflo
drag-noflo
polymer
drag-polymer

@bergie
Copy link
Member

bergie commented Oct 29, 2013

I think big part of this is that we still run the whole gesture data gathering operation after each pointermove, while we really are only interested in the coordinates moved (and gesture end). It might make sense to set up a shortcut earlier in the flow than we now do once gesture has been detected. We really don't need things like angle, distance, and speed after that.

@forresto
Copy link
Collaborator Author

fixing in pointergestures

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants