RE: Blink does not plan to implement pointer events

Responding to two different replies inline:

On Tue, Aug 19, 2014 at 7:41 AM, Rick Byers <> wrote:
> It's not just that it's heavy (talking with Jacob it appears we have about the same hit testing costs as IE - roughly 2% of the 16ms frame budget).  

This figure was taken on the lowest-end hardware I had available at the time (which is no longer even on the market AFAIK) in one of the most complex hit-testing scenarios I could concoct. Typical costs are much lower. In 3 years of implementation experience (which includes not just on the web but also in "native" Windows Store apps written in JS), we've not seen perf traces in real world apps that show this preventing apps from competing with native performance.

> There are certainly ways we could improve it, but at the cost of additional complexity that could be spent on improving perf elsewhere.  Developers tell us that performance is the #1 reason they choose native mobile platforms over the web (which is the #1 problem we're trying to tackle).  As such we're essentially unwilling to make any new design choices which put the web at an inherent performance disadvantage relative to Android and iOS native platforms.

But you're going to spend way more engineering costs exploring how to make touch events have features (and scroll/zoom performance) of pointer events. At the end of that venture, I highly suspect you'll only have gotten *some* of the pointer events benefits. Further, I doubt that will result in increased rationality for Touch Events (e.g. something like firing Touch Events for mouse input makes it even less rational).

On Wed, Aug 20, 2014 at 2:18 PM, Arthur Stolyar <> wrote:
>> The hit-testing cost is already removed for pointer-events if you do set a 'normal' pointer capture. The hit-testing cost is only incurred if you don't set a pointer capture (because it has to compute the element owning the event at every single pointer move, like it currently happens for the mouse events in all desktop browsers).
>> Additonnally, any sane gesture library will definitely set a pointer capture for you, so this isn't something you really need to worry about.
> As I see here: in note section:
> | When pointer capture is set, pointerover, pointerout, pointerenter, and pointerleave events are only generated when crossing the boundary of the element that has capture as other elements can no longer be targeted by the pointer. This has the effect of suppressing these events on all other elements. |
> And as I know that means that there still 'll be hit-testing after setPointerCapture because browser needs to know when pointer leaves/enters boundaries of captured element. 

It's theoretically possible for an implementation to build an optimized "simple hit test" for the pointer capture scenario that would have negligible perf impact, since you only have to detect transitions in and out of a single element (computing the hittable region for the capture node is a bit tough in some scenarios, but doable). But we don't currently implement that as we've never seen the hit-test costs impact a developer's ability to build performant apps. 

If this really starts to be an issue for developers, we've got a number of options we can consider at that time.

1) Attempt the above mentioned optimizations
2) Consider a setPointerCapture({ trackBoundaries: false}) type approach
3) Investigate what we can do to improve hit testing perf in general
4) Consider a way to let pages turn on implicit capture without boundary tracking

In the world of performance though (whether we're talking web apps or native apps), panning & zooming is key. THIS is what developers are spending lots and lots of energy trying to fix. It's in just about every app these days. With the async threading and compositor optimizations that Pointer Events allow and Touch Events do not, we're able to make improvements in scrolling/zooming latency by dozens to hundreds of milliseconds--two orders of magnitude greater than the hit-testing costs.  Yes, that's a per-touch savings. But in user perception, panning/zooming latency is blatantly obvious compared to a potential dropped frame (if you believe hit-testing cost will cause this in real apps).

tl;dr; - hit-testing cost keeps going down. hit-testing cost has never been known to affect app perf in IE or Windows apps. if it becomes a problem, we've got options. Microsoft is open to future API proposals on how to mitigate if participants truly believe this is an issue.


Received on Wednesday, 20 August 2014 22:30:14 UTC