- From: Joe Pea via GitHub <sysbot+gh@w3.org>
- Date: Tue, 12 Jan 2021 22:24:11 +0000
- To: public-pointer-events@w3.org
> To translate that world to the pointerevent world we had to introduce this notion of implicit capture. Ah, I see. Thanks for explaining! > I remember the hit-testing cost considering the high sampling rate of touch screens on phones were high enough > But having devices that do 120Hz sampling of touch moves on phones (meaning you might be getting two touch moves in a frame) I believe there is no need to run the events any faster than the animation loops (requestAnimationFrame) can run. From what I've seen in Chrome, user events fire at most once between animation frames (in the testing I've done). Which makes sense: no need to calculate things more than once just to render it once. If rAF is 60fps, then events should be at most 60fps too. `getCoalescedEvents` is interesting (and probably hardly used, I've never heard of it and I've been around for a while). I see that it could be useful for calculating a better movement curve for example, but the handler still doesn't need to run more than once per rAF. No handler ever needs to run faster than the screen will re-draw, I believe. And these days phones are fast. I play http://krunker.io on my phone. Would applications break if the default was changed to no capturing by default? (Also the terminology can be confused with event capture phases). -- GitHub Notification of comment by trusktr Please view or discuss this issue at https://github.com/w3c/pointerevents/issues/346#issuecomment-759075905 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 12 January 2021 22:24:13 UTC