Re: Blink does not plan to implement pointer events

Thank you for detailed answer. As I know PointerEvents polyfills have
difficulties with PointerEvents hit-testing model (for pointermove even
with pointer-capture) and this is main reason why I proposed
trackBoundaries: false; option. It gives legal way for polyfills to disable
hit-testing on each move (instead of have their own option which 'll be not
compatible with native realizations).

Polyfills are important because WebKit absolutely (for now?) does not plan
to support PointerEvents. Also, in the world there Blink 'll not support
PointerEvents no one 'll need them. Libraries like Hammer 'll dominant.
This situation almost here, since I heard about two surprising news: IE for
Mobile implemented TouchEvents and Blink 'll not plan to implement
PointerEvents.

Many realizations of same user input is really hell for developers,
especially for new web developers. This world looks like people still 'll
develop sites for WebKit (TouchEvents) only or 'll use popular libraries
like Hammer and never think about TouchEvents or PointerEvents.. or
something, that 'll not matter in second case. No one 'll need those event
models.

I am probably now looks like a pessimist, but which world you can image
with two different input models for touch? Remember about IE attachEvents
and W3C addEventListener. Many years no one used polyfill for
addEventListener, all used libraries like jQuery, MooTools and so on. And
that is still here. Many people still need to support IE8.

It's really worst idea to have PointerEvents and TouchEvents
simultaneously. Do not do same mistakes as 10 years ago, please.

2014-08-21 1:29 GMT+03:00 Jacob Rossi <Jacob.Rossi@microsoft.com>:

> Responding to two different replies inline:
>
> On Tue, Aug 19, 2014 at 7:41 AM, Rick Byers <rbyers@chromium.org> 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 <nekr.fabula@gmail.com>
> 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:
> https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html#setting-pointer-capture
> 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.
>
> -Jacob
>



-- 
@nekrtemplar <https://twitter.com/nekrtemplar>