Re: [pointerevents] Should pointerover and pointerenter work on mobile? (#346)

It was years ago obviously and the numbers might have changed recently. Off the top of my head I remember the hit-testing cost considering the high sampling rate of touch screens on phones were high enough (we do have internal metrics on that) for us not wanting to introduce that regression. Note that it would have been a regression vs the state of the web at the time that touchmove events don't do hit-test and always go to the first element you touch. To translate that world to the pointerevent world we had to introduce this notion of implicit capture.

To put the numbers into perspective if you would like to achieve a 60fps page then you would have ~16 ms time budget for each frame. Obviously different parts of this budget goes towards different parts of the browser doing the work as well as developer doing some js logic. But having devices that do 120Hz sampling of touch moves on phones (meaning you might be getting two touch moves in a frame) spending 1-2 ms on hit-testing would eat quite a lot of the budget in a frame.

Also note that we are running things on a mobile device for touch screens mostly and the processing power + battery consideration vs a desktop environment that you would usually expect mouse events are different. So that was why web at the time didn't care doing hit-testing on all mouse move events and most likely why you didn't experience any performance issues with mouseover stuff. It was mostly desktop and it could handle it. Obviously over time as mouse devices also started to up the sampling to like 1000Hz we started introducing other features such as [coaleased events]( to reduce the overhead of hit-testing and whatnot but that's just some boring history :)

GitHub Notification of comment by NavidZ
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Tuesday, 12 January 2021 19:26:31 UTC