Whatever you think of pointer events (and Chrome's decision not to implement them), this article contains an extremely misleading pair of graphs and associated text.
In this basic example test page, developed by Rick Byers on the Chrome team, with touch events in IE we can see the first frame of panning doesn’t render until after the touch contact has moved for 1020ms and travelled 4.8cm, which is clearly perceivable by the user. Simply replacing Touch Event handlers with Pointer Event handlers reduces this latency to just 31ms and 0.3cm—a greater than 32x improvement.
Well, yeah, if you take a test page which /spins in a while loop until 1000ms has passed/, then you can get a 32x improvement by making it asynchronous. In real life cases, I'd expect the factor to be rather different.
4 comments
[ 4.3 ms ] story [ 17.9 ms ] threadDeveloping for other browsers is, well, developing; getting it to "just work" in IE is, well, "just work".
In this basic example test page, developed by Rick Byers on the Chrome team, with touch events in IE we can see the first frame of panning doesn’t render until after the touch contact has moved for 1020ms and travelled 4.8cm, which is clearly perceivable by the user. Simply replacing Touch Event handlers with Pointer Event handlers reduces this latency to just 31ms and 0.3cm—a greater than 32x improvement.
Well, yeah, if you take a test page which /spins in a while loop until 1000ms has passed/, then you can get a 32x improvement by making it asynchronous. In real life cases, I'd expect the factor to be rather different.
If by "just work" you mean "have an acceptable-ish retrofit UX in a touch device" then yeah.