Expose fractional TouchEvent coordinates

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
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=175726

[Rick Byers, 2014-06-06 02:24:48]

Emil,
Please take a look.

I spent a bit of time exploring what it would look like if I were to add
FloatPoint versions of everything Widget::convertFromContainingWindow depends
on, and as you suspected it's quite huge (and since we probably wouldn't want to
convert from ints to floats in the common case, there'd be a bunch of near
duplicate code).  I think the guidance you gave me offline is definitely right -
we should just rely on this interpolation hack for now.

[eae, 2014-06-06 16:23:53]

LGTM w/nit.

https://codereview.chromium.org/298133003/diff/80001/Source/core/dom/Touch.h
File Source/core/dom/Touch.h (right):

https://codereview.chromium.org/298133003/diff/80001/Source/core/dom/Touch.h#...
Source/core/dom/Touch.h:55: double clientX() const { return m_clientPos.x(); }
You might want to use float here instead to avoid unnecessary conversion between
float and double to the extent possible.

[Rick Byers, 2014-06-06 17:02:43]

https://codereview.chromium.org/298133003/diff/80001/Source/core/dom/Touch.h
File Source/core/dom/Touch.h (right):

https://codereview.chromium.org/298133003/diff/80001/Source/core/dom/Touch.h#...
Source/core/dom/Touch.h:55: double clientX() const { return m_clientPos.x(); }
On 2014/06/06 16:23:53, eae wrote:
> You might want to use float here instead to avoid unnecessary conversion
between
> float and double to the extent possible.

Yeah, this is the public API which we defined in the standard to be double in
order to be consistent with all the other standard fractional co-ordinate APIs
(scrollTop, etc.).  I assume we'd do the conversion to double anyway since
JavaScript numbers are all double (I assume v8 doesn't try to predict when it
can use single-precision registers/instructions, does it?).

I did find one place where we were calling this within blink.  I've  exposes the
FloatPoint and used that instead for that case.

[eae, 2014-06-06 17:03:55]

LGTM

On 2014/06/06 17:02:43, Rick Byers wrote:
> https://codereview.chromium.org/298133003/diff/80001/Source/core/dom/Touch.h
> File Source/core/dom/Touch.h (right):
> 
>
https://codereview.chromium.org/298133003/diff/80001/Source/core/dom/Touch.h#...
> Source/core/dom/Touch.h:55: double clientX() const { return m_clientPos.x(); }
> On 2014/06/06 16:23:53, eae wrote:
> > You might want to use float here instead to avoid unnecessary conversion
> between
> > float and double to the extent possible.
> 
> Yeah, this is the public API which we defined in the standard to be double in
> order to be consistent with all the other standard fractional co-ordinate APIs
> (scrollTop, etc.).  I assume we'd do the conversion to double anyway since
> JavaScript numbers are all double 

Correct.

> 
> I did find one place where we were calling this within blink.  I've  exposes
the
> FloatPoint and used that instead for that case.

Thanks!

[eae, 2014-06-06 17:04:59]

At some point (but not now!) we might want to introduce double versions of the
Float* geometry classes (or change the float ones to double), would at least be
interesting to see how much that would increase the memory usage.

[Rick Byers, 2014-06-06 18:34:31]

On 2014/06/06 17:04:59, eae wrote:
> At some point (but not now!) we might want to introduce double versions of the
> Float* geometry classes (or change the float ones to double), would at least
be
> interesting to see how much that would increase the memory usage.

Yeah, I was wondering about that.  Heck, it would be interesting to just
redefine FloatSize/FloatPoint to actually contain doubles and see how much
things change.

[Rick Byers, 2014-06-06 20:31:17]

+aelias for OWNERS in Source/web

[aelias_OOO_until_Jul13, 2014-06-06 20:56:28]

On 2014/06/06 20:31:17, Rick Byers wrote:
> +aelias for OWNERS in Source/web

lgtm

[Rick Byers, 2014-06-06 21:08:44]

The CQ bit was checked by rbyers@chromium.org

[commit-bot: I haz the power, 2014-06-06 21:09:39]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/rbyers@chromium.org/298133003/120001

[commit-bot: I haz the power, 2014-06-06 22:18:50]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  linux_blink_dbg on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/linux_blink_dbg/builds/1...)
  mac_blink_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/mac_blink_rel/builds/10661)
  win_blink_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/win_blink_rel/builds/11060)

[commit-bot: I haz the power, 2014-06-06 22:37:45]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-06-06 22:37:46]

Try jobs failed on following builders:
  mac_blink_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/mac_blink_rel/builds/10683)

[Rick Byers, 2014-06-07 00:09:53]

The CQ bit was checked by rbyers@chromium.org

[commit-bot: I haz the power, 2014-06-07 00:11:00]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/rbyers@chromium.org/298133003/120001

[commit-bot: I haz the power, 2014-06-07 03:38:32]

Change committed as 175726