New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 8 users

Issue metadata

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

Blocked on:
issue 329354

Blocking:
issue 328503
issue 379150



Sign in to add a comment

Touch event co-ordinates are quantized to CSS pixels

Project Member Reported by skyos...@chromium.org, Nov 27 2013

Issue description

The touch coordinates[1] that are sent to Javascript touch handlers are represented as integer CSS pixels. Typically the original touch events from the system have physical pixel precision or better, so this conversion is lossy.

This means that unless pages set up their viewport tags so that CSS pixels match physical pixels, they will receive touch events with less precision.

One fix would be to make touch events have float coordinates, but that could have adverse knock on effects (e.g. breaking sites).

[1] https://developer.mozilla.org/en-US/docs/Web/API/Touch?redirectlocale=en-US&redirectslug=DOM%2FTouch
 
Cc: rbyers@chromium.org
John noticed that the CSSOM View Module editor's draft (http://dev.w3.org/csswg/cssom-view/) is making scroll coordinates as well as mouse and pointer events use doubles instead of longs. The current specs use longs.

If we switched to doubles we *think* everything would mostly just work. The only corner case we came up with was when you scroll the page to a position that isn't an even multiple of a physical pixel. In this case the screenX/Y properties of a touch event should be transformed so that they give the offset to the document coordinate that is *drawn* at the top left corner of the screen instead being an offset from (0, 0). This is because layer scroll coordinates are snapped to physical pixels.

Comment 2 Deleted

Comment 3 by rbyers@chromium.org, Dec 13 2013

Status: Available
I think we're blocked on standardization / discussion with other browser vendors here.  I've filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=24095 suggesting that CSS OM should treat both MouseEvent and Touch the same way.

It's not clear to me how important this is.
I don't think this is super urgent. I just stumbled on this when trying to replicate native scrolling with JS. This essentially means that JS scrolling happens in coarse increments, but that's only visible if you scroll really slowly.

Comment 5 by nduca@chromium.org, Dec 13 2013

I think we should consider this important for silky smooth web apps, so we probably need to keep this moving along.

Comment 6 by rbyers@chromium.org, Dec 13 2013

Sami, you're saying chrome Android supports single-physical-pixel native scrolling?  Does this work for documents and DIVs?  I thought blink would have issues with this.  Maybe it works only for composited scrolling and blink only knows about the nearest integer?  Eg. see this old google internal G+ thread: https://plus.sandbox.google.com/103099260058609329507/posts/ZbZy23Yc5nQ
> Sami, you're saying chrome Android supports single-physical-pixel native scrolling? Does this work for documents and DIVs?

Yes, single-pixel scrolling works for both cases. This has been true for document-level scrolling since forever, but I remember divs snapping to the nearest CSS coordinate at some point, but looks like that has been fixed.

Re: the G+ thread, the problem with the old Nexus 7 was that the touch panel gave us events with a poor resolution to begin with.

Comment 8 by rbyers@chromium.org, Dec 18 2013

Blockedon: chromium:329354
Owner: rbyers@chromium.org
Status: Assigned
Awesome!  And this is in both main thread and impl-thread scrolling scenarios?  I've filed 329354 to make Aura consistent with this.

And yes, I agree we should expose this to JS as well.  I've started a touchevents community group thread on this topic here: http://lists.w3.org/Archives/Public/public-touchevents/2013Dec/0003.html.

I've also started a thread on public-pointerevents (http://lists.w3.org/Archives/Public/public-pointer-events/2013OctDec/0074.html), but pointer events will pick this up "for free" since PointerEvent inherits from MouseEvent
> Awesome!  And this is in both main thread and impl-thread scrolling scenarios?

Looks main thread scrolled overflow divs don't get sub-pixel scrolling, e.g., here http://css-tricks.com/almanac/properties/o/overflow/. It's pretty noticeable once you zoom in.
Cc: johnme@google.com
Cc: tdres...@chromium.org

Comment 12 by ojan@chromium.org, Mar 11 2014

What specific effect do you see on http://css-tricks.com/almanac/properties/o/overflow/ ? I tried loading it on a Nexus 5 and it all seemed to work as expected (i.e. scrolling was smooth) even when I zoomed in.

Comment 13 by ojan@chromium.org, Mar 11 2014

Cc: ojan@chromium.org
#12: Zoom in on the first code sample on the dark background and slowly scroll the CSS horizontally. Notice that it scroll in visible jumps instead of physical pixel increments like the rest of the page.
Summary: Javascript input events and scroll offsets are quantized to CSS pixels (was: Javascript touch events are quantized to CSS pixels)
Let's generalize this to cover the scroll offset case too (since the CSS OM spec changes should cover both).
Cc: sim...@opera.com

Comment 17 by e...@chromium.org, Mar 18 2014

Before we change this we should also try to get the specification changed for scrollTop, scrollLeft, scrollWidth, and scrollHeight to return and accept fractional values. Changing the events without changing the scroll* values is likely to cause more problems than it solves.

http://www.w3.org/TR/cssom-view/#dom-element-scrolltop


Comment 19 by e...@chromium.org, Mar 18 2014

Cc: e...@chromium.org
We've discussed this in the past and the spec was the one thing holding us back from implementing it (shipping it is another question entirely). IE has a per-document setting (msCSSOMElementFloatMetrics) allowing the page author to opt in to the precise values but I'd rather not go down that path.

How about we implement it behind an experimental flag and see what the web community thinks of it?
Great!  Yes that's my proposal on the input-dev thread too (https://groups.google.com/a/chromium.org/forum/#!topic/input-dev/FNTZruEEDkE).

Comment 21 by e...@chromium.org, Mar 18 2014

If we can get consensus on that plan I volunteer to implement it.
Blockedon: chromium:336807
Labels: M-36
Owner: e...@chromium.org
We just agreed in input-dev OKR planning that this needs to be a priority for us in Q2 and we should totally push forward with making the changes behind a flag (it'll be the next thing we bump up against trying to get hidey bars and pull to refresh looking perfect after we resolve sync-scroll).

Thanks for volunteering Emil!  Once  issue 336807  is done, I think plumbing floating point event co-ordinates out to JS should be trivial (probably just need to push down from WebTouchPoint to PlatformTouchPoint and out through WebCore::Touch.  So it probably makes sense to do it at the same time (and controlled by the same flag) as the scroll offsets.  But feel free to carve out any pieces you don't want to deal with into separate bugs.
First step is probably an intent-to-implement on blink-dev, make sure we have consensus there.  Emil, do you want to send that or should I?

Comment 24 by e...@chromium.org, Mar 18 2014

I can take care of that.
Blockedon: -chromium:336807
 Issue 336807  isn't blocking at this point - the only remaining work to be done there is some chromium side cleanup.
Blocking: chromium:328503

Comment 27 by bokan@chromium.org, Mar 31 2014

Cc: bokan@chromium.org

Comment 28 by e...@chromium.org, Apr 8 2014

See  bug 360889  for the change to make offset[Top|Left|Width|Height], client[Top|Left|Width|Height] and scroll[Top|Left|Width|Height] support sub-pixel values.

Comment 29 by e...@chromium.org, Apr 8 2014

Blockedon: chromium:360889
Blockedon: -chromium:360889
Owner: rbyers@chromium.org
Summary: Javascript input events are quantized to CSS pixels (was: Javascript input events and scroll offsets are quantized to CSS pixels)
Ok, let's split this back up and have this bug focus only on the input event side.  We probably need to produce an updated TouchEvent spec somehow, which makes this problem a little different.  Assigning to me to track that part.
Labels: -M-36 M-37
Labels: Hotlist-Input-Dev
Status: Started
WebKit but for fractional touch co-ordinates: https://bugs.webkit.org/show_bug.cgi?id=133180
Summary: Touch event co-ordinates are quantized to CSS pixels (was: Javascript input events are quantized to CSS pixels)
Updating summary to make it clear that it's only touch events we're changing here (should ideally also change mouse, but that's less important).

A good way to see the impact here is to try drawing slowly in a simple touch drawing app like http://www.rbyers.net/paint.html#points (which draws a single physical pixel point per touchmove event).  You have to be moving pretty slowly to make a really noticeable difference (since we send at most one touch event per frame), but when you do the difference can be dramatic.  Attached are some screenshots of drawing with integer co-ordinates and float co-ordinates in Chrome on a Nexus 5 (which has 1 CSS px = 3 hardware pixels).
floats-ftw.png
54.3 KB View Download
ints-suck.png
36.1 KB View Download
float-circle.png
23.8 KB View Download
int-circle.png
10.0 KB View Download
The difference is also pretty noticeable when dragging something around slowly. eg: http://jsbin.com/idojig/2/quiet
Blocking: chromium:379150
In-progress CL is here: https://codereview.chromium.org/298133003/
Project Member

Comment 38 by bugdroid1@chromium.org, Jun 6 2014

------------------------------------------------------------------
r275340 | rbyers@chromium.org | 2014-06-06T05:24:57.253750Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/shell/renderer/test_runner/event_sender.cc?r1=275340&r2=275339&pathrev=275340
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/shell/renderer/test_runner/event_sender.h?r1=275340&r2=275339&pathrev=275340

Enable floating point touch co-ordinates in EventSender

WebTouchPoint has used floating point co-ordinate and radius values for awhile, but we've never allowed generating non-integer values via EventSender.

BUG= 323935 

Review URL: https://codereview.chromium.org/316303002
-----------------------------------------------------------------
Project Member

Comment 39 by bugdroid1@chromium.org, Jun 6 2014

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

commit f3d5009d2029c220ea0ed0e358cffd35c871d04e
Author: rbyers@chromium.org <rbyers@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Fri Jun 06 05:24:57 2014

Enable floating point touch co-ordinates in EventSender

WebTouchPoint has used floating point co-ordinate and radius values for awhile, but we've never allowed generating non-integer values via EventSender.

BUG= 323935 

Review URL: https://codereview.chromium.org/316303002

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@275340 0039d316-1c4b-4281-b951-d872f2087c98


Project Member

Comment 40 by bugdroid1@chromium.org, Jun 7 2014

The following revision refers to this bug:
  http://src.chromium.org/viewvc/blink?view=rev&rev=175726

------------------------------------------------------------------
r175726 | rbyers@chromium.org | 2014-06-07T03:38:24.403901Z

Changed paths:
   M http://src.chromium.org/viewvc/blink/trunk/Source/platform/Widget.cpp?r1=175726&r2=175725&pathrev=175726
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/events/touch/touch-coords-in-zoom-and-scroll-expected.txt?r1=175726&r2=175725&pathrev=175726
   M http://src.chromium.org/viewvc/blink/trunk/Source/platform/scroll/ScrollView.cpp?r1=175726&r2=175725&pathrev=175726
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/dom/Document.idl?r1=175726&r2=175725&pathrev=175726
   M http://src.chromium.org/viewvc/blink/trunk/Source/platform/Widget.h?r1=175726&r2=175725&pathrev=175726
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/events/touch/document-create-touch-expected.txt?r1=175726&r2=175725&pathrev=175726
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/events/touch/touch-fractional-coordinates.html?r1=175726&r2=175725&pathrev=175726
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/dom/Touch.idl?r1=175726&r2=175725&pathrev=175726
   M http://src.chromium.org/viewvc/blink/trunk/Source/platform/scroll/ScrollView.h?r1=175726&r2=175725&pathrev=175726
   M http://src.chromium.org/viewvc/blink/trunk/Source/web/WebInputEventConversion.cpp?r1=175726&r2=175725&pathrev=175726
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/page/EventHandler.cpp?r1=175726&r2=175725&pathrev=175726
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/inspector/InspectorDOMAgent.cpp?r1=175726&r2=175725&pathrev=175726
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/events/touch/resources/frame-touchevent-forwarder.html?r1=175726&r2=175725&pathrev=175726
   M http://src.chromium.org/viewvc/blink/trunk/Source/platform/geometry/FloatSize.h?r1=175726&r2=175725&pathrev=175726
   M http://src.chromium.org/viewvc/blink/trunk/Source/web/tests/WebInputEventConversionTest.cpp?r1=175726&r2=175725&pathrev=175726
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/dom/Document.cpp?r1=175726&r2=175725&pathrev=175726
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/events/touch/touch-fractional-coordinates-expected.txt?r1=175726&r2=175725&pathrev=175726
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/dom/Touch.cpp?r1=175726&r2=175725&pathrev=175726
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/dom/Document.h?r1=175726&r2=175725&pathrev=175726
   M http://src.chromium.org/viewvc/blink/trunk/Source/platform/PlatformTouchPoint.h?r1=175726&r2=175725&pathrev=175726
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/dom/Touch.h?r1=175726&r2=175725&pathrev=175726
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/events/touch/touch-coords-in-zoom-and-scroll.html?r1=175726&r2=175725&pathrev=175726
   M http://src.chromium.org/viewvc/blink/trunk/Source/platform/geometry/FloatPoint.h?r1=175726&r2=175725&pathrev=175726
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/inspector/InspectorInputAgent.cpp?r1=175726&r2=175725&pathrev=175726

Expose fractional TouchEvent coordinates

Previously TouchEvents had their co-ordinates truncated to integers.
By supporting sup-pixel precision we get smoother dragging and line 
drawing at slow speeds on high-dpi devices or when zoomed.

Intent to ship thread: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/J0Lca9fCuNw

Tests depend on EventSender change here: https://src.chromium.org/viewvc/chrome?view=rev&revision=275340

BUG= 323935 

Review URL: https://codereview.chromium.org/298133003
-----------------------------------------------------------------
Status: Fixed

Sign in to add a comment