W3C home > Mailing lists > Public > public-pointer-events@w3.org > July to September 2013

Blink pointer events implementation update

From: Rick Byers <rbyers@google.com>
Date: Tue, 30 Jul 2013 10:45:04 -0230
Message-ID: <CAFUtAY84dOX2HL4EiBd2Y-rC-vDD8htmuMVXr5rERyxVaUro5Q@mail.gmail.com>
To: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
Here's an update on the implementation status of pointer events in blink
and chrome. *tl;dr*: touch-action requires some substantial
re-architecting, and one of the first phases of this (reliable
compositor-thread hit testing) has now landed.  But there is still a lot of
complex work left before touch-action can be implemented with the correct
performance properties.

*Details*
As we've discussed before, implementing touch-action (
http://crbug.com/241964) is our top priority (since it's the most
complicated part, the main problem for polyfills, and provides benefit to
touch events as well as pointer events).  Design doc here:
https://docs.google.com/a/chromium.org/document/d/1CV2AXyrdPdGSRypAQcfGrgQVuWYi50EzTmVsMLWgRPM/edit

One of the main pieces needed to implement touch-action with the
performance properties we want is a mechanism for doing touch hit testing
on the compositor thread.  Only the main thread has access to the DOM so
it's non-trivial to correlate anything with the co-ordinate of a touch from
any other thread.  Chrome recently got a compositor hit testing mechanism
for avoiding sending touch events for regions that have no handlers (
http://www.chromium.org/developers/design-documents/compositor-hit-testing)
but it was very limited (inaccurate).  Last week I landed a major
re-implementation of this system to be sufficiently accurate for
touch-action (http://crbug.com/248522).  At the same time, a cool new
feature was added to chrome dev tools that lets you visualize these regions
(https://plus.google.com/115788095648461403871/posts/LXKEENhnQSD)

Immediate next steps (next several weeks):
- hit testing performance improvements
- enable a naive implementation of touch-action behind the
--enable-experimental-web-platform-features flag (on top of the basic
touch-action CSS support I've already landed)
- add initial experimental support for my proposed touch-action-delay CSS
property (necessary for compat with the existing touch event model
supported by non-IE browsers)
- expand polymer PointerEvents polyfill to use browser touch-action support
when present and look for compat issues on real sites.

Longer term I still need to finalize the design for implementing
touch-action-delay (again some major changes are necessary here) and wire
it up to the hit testing system so we can implement touch-action with the
desired performance properties.  This is still at least another few months
of work :-(.  Once we've got an experimental version working, I'll start
more serious discussions around standardizing touch-action-delay.

Rick
Received on Tuesday, 30 July 2013 13:15:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:20:25 UTC