- From: Jacob Rossi via GitHub <sysbot+gh@w3.org>
- Date: Thu, 25 Jun 2015 04:08:14 +0000
- To: public-pointer-events@w3.org
We don't throttle our pointer events today. So they get put in our queue as soon as the device driver and OS send it to us. That gets dispatched when the message loop is pumped. Our touch events are throttled to the vsync (like RAF), however. The difference here is a tradeoff between performance and fineness of detail. A painting app might prefer more events per frame for finer detail. A game just wants the latest data at the time of the frame. Given you can throttle your expensive handling yourself (using a library such as you're describing), I prefer the former behavior. That said, I think allowing flexibility here on this tradeoff in implementations is desirable. In the scenario of this library, don't you just want to have the latest data no matter when it fired? Consider our PE implementation (I'll call it "JIT events" :-)). We wouldn't want a requirement to guarantee firing events for all pointers before the next frame because that could mean arbitrarily refiring events with the same data just to meet the requirement. The library should IMO just handle all the events and update pointers accordingly. Then when RAF comes around, it has the freshest data possible. Whether all pointers got an event in that frame doesn't much matter. -- GitHub Notif of comment by jacobrossi See https://github.com/w3c/pointerevents/issues/9#issuecomment-115097172
Received on Thursday, 25 June 2015 04:08:16 UTC