New issue
Advanced search Search tips

Issue 710442 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Apr 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

PointerEvent timestamps should be set from WebInputEvent timestamps whenever applicable.

Project Member Reported by rbyers@chromium.org, Apr 11 2017

Issue description

Chrome Version: 59.0.3047.0
OS: Linux

What steps will reproduce the problem?
(1) Open https://rbyers.github.io/event-timing.html on Linux
(2) Drag with the mouse

What is the expected result?
I assume my mouse is operating at 120hz.  So I expected to see coalesced events whose timestamps are relatively evenly spaced (since I believe they should be getting majidvp@'s OS-timestamp logic).

What happens instead?
The coalesced events all seem to have roughly the same timestamp:

frame[0]: events 0.5ms
frame[1] 14.2ms: events
frame[2] 17ms: events 0.2ms(0.4)
frame[3] 17.5ms: events 0.1ms(0.2, 0.1)
frame[4] 16.1ms: events 0.1ms(0.1, 0.1)
frame[5] 16.7ms: events 0.1ms(0.1, 0.1)
frame[6] 16.7ms: events 0.1ms(0.1, 0.1)
frame[7] 16.8ms: events 0.1ms(0.1, 0.1)
frame[8] 17.9ms: events 0.2ms(0.3, 0.3)
frame[9] 15.9ms: events 0.1ms(0.2, 0.2)
frame[10] 16.5ms: events 0.1ms(0.3, 0.2)
frame[11] 16.9ms: events 0.1ms(0.2, 0.2, 0.2)
frame[12] 16.5ms: events 0.1ms(0.2, 0.2)
frame[13] 16.6ms: events 0.1ms(0.2, 0.2)
frame[14] 16.4ms: events

In contrast here's what I see from Firefox on the same machine.  Presumably this represents the raw event stream, I'd expect to see a similar pattern from the getCoalescedEvents timestamps in Chrome.

frame[0]: events 2.5ms
frame[1] 16.9ms: events 14.7ms 6.9ms
frame[2] 16.1ms: events 15ms 6.9ms
frame[3] 18.9ms: events 18ms 10.1ms 1.9ms
frame[4] 16ms: events 9.9ms 1.9ms
frame[5] 16.5ms: events 10.4ms 2.6ms
frame[6] 15.6ms: events 10ms 2ms
frame[7] 16.7ms: events 10.8ms 2.8ms
frame[8] 17.1ms: events 11.9ms 4.1ms
frame[9] 24.8ms: events 1.6ms
frame[10] 8.6ms: events 5.3ms
frame[11] 15.9ms: events
frame[12] 17.2ms: events 6.4ms
 

Comment 1 by rbyers@chromium.org, Apr 11 2017

Description: Show this description
Labels: Hotlist-Input-Dev
Owner: nzolghadr@chromium.org
Status: Assigned (was: Untriaged)
I think the MouseEvent.timestamp != PointerEvent.timestamp largely because in our implementation PointerEvents use the PointerEventInit code path and timestamp isn't in the EventInit.idl..

This causes use to use this code:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/events/Event.cpp?type=cs&l=106

We probably should avoid calling Ui::TimeTicksForNow(...) for every coalesced event as well :-)


Specifically we either need to add an argument to Event's constructor in the C++ code.. Or fix https://github.com/whatwg/dom/issues/76

Comment 4 by mustaq@chromium.org, Apr 13 2017

Cc: mustaq@chromium.org
Labels: -Pri-3 M-59 OS-All Pri-2
Yikes, the blame goes to me here: I originally started using *EventInit to avoid passing a long list of parameters to MouseEvent but missed the impact on timestamp!


Let's add an optional parameter to all *Init based constructors now because the spec issue won't get fixed soon (currently blocked on high-resolution timestamps for events).

Comment 5 by mustaq@chromium.org, Apr 13 2017

Summary: PointerEvent timestamps should be set from WebInputEvent timestamps whenever applicable. (was: Coalesced points timestamps incorrect under raf-aligned mouse input)

Comment 6 by rbyers@chromium.org, Apr 17 2017

I'm pretty sure we will want to fix that spec issue.  Perhaps we should just land a status=experimental addition to EventInitDict now?  We can rely on the C++ plumbing for that here, even though the dictionary addition won't actually be web-exposed yet...
Project Member

Comment 7 by bugdroid1@chromium.org, Apr 24 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c9291d203486935075ef689647fb071e99232f2a

commit c9291d203486935075ef689647fb071e99232f2a
Author: nzolghadr <nzolghadr@chromium.org>
Date: Mon Apr 24 18:18:54 2017

Add time stamp to the constructor of the events

To match the pointerevent and its corresponding
mouse and touch events time stamps we need to
have the time stamp in the constructor parameter.

Note that having the time stamp in the EventInit
dictionary is being debated as part of this issue:
https://github.com/whatwg/dom/issues/76

BUG= 710442 

Review-Url: https://codereview.chromium.org/2834183002
Cr-Commit-Position: refs/heads/master@{#466690}

[modify] https://crrev.com/c9291d203486935075ef689647fb071e99232f2a/third_party/WebKit/LayoutTests/external/wpt/pointerevents/extension/pointerevent_coalesced_events_attributes-manual-expected.txt
[modify] https://crrev.com/c9291d203486935075ef689647fb071e99232f2a/third_party/WebKit/LayoutTests/external/wpt/pointerevents/extension/pointerevent_coalesced_events_attributes-manual.html
[modify] https://crrev.com/c9291d203486935075ef689647fb071e99232f2a/third_party/WebKit/LayoutTests/external/wpt/pointerevents/pointerevent_suppress_compat_events_on_drag_mouse-manual.html
[modify] https://crrev.com/c9291d203486935075ef689647fb071e99232f2a/third_party/WebKit/Source/core/events/Event.cpp
[modify] https://crrev.com/c9291d203486935075ef689647fb071e99232f2a/third_party/WebKit/Source/core/events/Event.h
[modify] https://crrev.com/c9291d203486935075ef689647fb071e99232f2a/third_party/WebKit/Source/core/events/MouseEvent.cpp
[modify] https://crrev.com/c9291d203486935075ef689647fb071e99232f2a/third_party/WebKit/Source/core/events/MouseEvent.h
[modify] https://crrev.com/c9291d203486935075ef689647fb071e99232f2a/third_party/WebKit/Source/core/events/PointerEvent.cpp
[modify] https://crrev.com/c9291d203486935075ef689647fb071e99232f2a/third_party/WebKit/Source/core/events/PointerEvent.h
[modify] https://crrev.com/c9291d203486935075ef689647fb071e99232f2a/third_party/WebKit/Source/core/events/PointerEventFactory.cpp
[modify] https://crrev.com/c9291d203486935075ef689647fb071e99232f2a/third_party/WebKit/Source/core/events/PointerEventFactory.h
[modify] https://crrev.com/c9291d203486935075ef689647fb071e99232f2a/third_party/WebKit/Source/core/events/PointerEventFactoryTest.cpp
[modify] https://crrev.com/c9291d203486935075ef689647fb071e99232f2a/third_party/WebKit/Source/core/events/UIEvent.cpp
[modify] https://crrev.com/c9291d203486935075ef689647fb071e99232f2a/third_party/WebKit/Source/core/events/UIEvent.h
[modify] https://crrev.com/c9291d203486935075ef689647fb071e99232f2a/third_party/WebKit/Source/core/events/UIEventWithKeyState.cpp
[modify] https://crrev.com/c9291d203486935075ef689647fb071e99232f2a/third_party/WebKit/Source/core/events/UIEventWithKeyState.h
[modify] https://crrev.com/c9291d203486935075ef689647fb071e99232f2a/third_party/WebKit/Source/core/input/PointerEventManager.cpp
[modify] https://crrev.com/c9291d203486935075ef689647fb071e99232f2a/third_party/WebKit/Source/core/input/PointerEventManager.h

Status: Fixed (was: Assigned)

Comment 9 by rbyers@chromium.org, May 25 2017

Labels: -M-59 M-60
Verified fixed in M60.  Now I see ~9-12ms delta on the getCoalescedEvents timestamps with the rAF time.  That's the ~5ms Android RESAMPLE_LATENCY plus the latency we add by aligning with vsync.

Sign in to add a comment