Make PointerEvent coordinates fractional for touch

third_party/WebKit/Source/core/events/MouseRelatedEvent.h

 /*
  * Copyright (C) 2001 Peter Kelly (pmk@post.com)
  * Copyright (C) 2001 Tobias Anton (anton@stud.fbi.fh-darmstadt.de)
  * Copyright (C) 2006 Samuel Weinig (sam.weinig@gmail.com)
  * Copyright (C) 2003, 2004, 2005, 2006 Apple Computer, Inc.
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Library General Public
  * License as published by the Free Software Foundation; either
  * version 2 of the License, or (at your option) any later version.
@@ skipping 23 matching lines @@
 // Internal only: Helper class for what's common between mouse and wheel events.
 class CORE_EXPORT MouseRelatedEvent : public UIEventWithKeyState {
  public:
   enum class PositionType {
     Position,
     // Positionless mouse events are used, for example, for 'click' events from
     // keyboard input.  It's kind of surprising for a mouse event not to have a
     // position.
     Positionless
   };
+
   // Note that these values are adjusted to counter the effects of zoom, so that
   // values exposed via DOM APIs are invariant under zooming.
-  int screenX() const { return m_screenLocation.x(); }
-  int screenY() const { return m_screenLocation.y(); }
-  const IntPoint& screenLocation() const { return m_screenLocation; }
-  int clientX() const { return m_clientLocation.x().toInt(); }
-  int clientY() const { return m_clientLocation.y().toInt(); }
-  int movementX() const { return m_movementDelta.x().toInt(); }
-  int movementY() const { return m_movementDelta.y().toInt(); }
-  const LayoutPoint& clientLocation() const { return m_clientLocation; }
+  // TODO(mustaq): Remove the PointerEvent specific code when mouse has
+  // fractional coordinates. See crbug.com/655786.
+  double screenX() const {
+    return isPointerEvent() ? m_screenLocation.x()
+                            : static_cast<int>(m_screenLocation.x());
+  }
+  double screenY() const {
+    return isPointerEvent() ? m_screenLocation.y()
+                            : static_cast<int>(m_screenLocation.y());
+  }
+
+  double clientX() const {
+    return isPointerEvent() ? m_clientLocation.x()
+                            : static_cast<int>(m_clientLocation.x());
+  }
+  double clientY() const {
+    return isPointerEvent() ? m_clientLocation.y()
+                            : static_cast<int>(m_clientLocation.y());
+  }
+
+  int movementX() const { return m_movementDelta.x(); }
+  int movementY() const { return m_movementDelta.y(); }
+
   int layerX();
   int layerY();
+
   int offsetX();
   int offsetY();
-  int pageX() const;
-  int pageY() const;
-  int x() const;
-  int y() const;
+
+  double pageX() const {
+    return isPointerEvent() ? m_pageLocation.x()
+                            : static_cast<int>(m_pageLocation.x());
+  }
+  double pageY() const {
+    return isPointerEvent() ? m_pageLocation.y()
+                            : static_cast<int>(m_pageLocation.y());
+  }
+
+  double x() const { return clientX(); }
+  double y() const { return clientY(); }
+
   bool hasPosition() const { return m_positionType == PositionType::Position; }
 
   // Page point in "absolute" coordinates (i.e. post-zoomed, page-relative
   // coords, usable with LayoutObject::absoluteToLocal) relative to view(), i.e.
   // the local frame.
-  const LayoutPoint& absoluteLocation() const { return m_absoluteLocation; }
-  void setAbsoluteLocation(const LayoutPoint& p) { m_absoluteLocation = p; }
+  const DoublePoint& absoluteLocation() const { return m_absoluteLocation; }
 
   DECLARE_VIRTUAL_TRACE();
 
  protected:
   MouseRelatedEvent();
   // TODO(lanwei): Will make this argument non-optional and all the callers need
   // to provide sourceCapabilities even when it is null, see
   // https://crbug.com/476530.
   MouseRelatedEvent(const AtomicString& type,
                     bool canBubble,
                     bool cancelable,
                     AbstractView*,
                     int detail,
                     const IntPoint& screenLocation,
                     const IntPoint& rootFrameLocation,
                     const IntPoint& movementDelta,
                     PlatformEvent::Modifiers,
                     double platformTimeStamp,
                     PositionType,
                     InputDeviceCapabilities* sourceCapabilities = nullptr);
 
   MouseRelatedEvent(const AtomicString& type,
                     const MouseEventInit& initializer);
 
-  void initCoordinates(const LayoutPoint& clientLocation);
+  void initCoordinates(const double clientX, const double clientY);
   void receivedTarget() final;
 
   void computePageLocation();
   void computeRelativePosition();
 
   // Expose these so MouseEvent::initMouseEvent can set them.
-  IntPoint m_screenLocation;
-  LayoutPoint m_clientLocation;
-  LayoutPoint m_movementDelta;
+  DoublePoint m_screenLocation;
+  DoublePoint m_clientLocation;
+  DoublePoint m_movementDelta;
 
  private:
-  LayoutPoint m_pageLocation;
-  LayoutPoint m_layerLocation;
-  LayoutPoint m_offsetLocation;
-  LayoutPoint m_absoluteLocation;
+  DoublePoint m_pageLocation;

[bokan, 2016/11/15 12:55:39]

Why double? We've recently settled the debate about scroll offsets to use
floats. Is this arbitrary or does this match some existing choices? Couldn't we
just keep these as LayoutPoint and convert to a float in the accessors?

[mustaq, 2016/11/15 15:21:15]

I learned somewhere that floats can't represent integer precision (=1) for very
"tall" pages, that's why MouseRelatedEvent had coordinates in LayoutUnits.
This is the only reason that motivated me to use DoublePoint instead of
FloatPoint here.

After your comment, I investigated further and couldn't see why LayoutUnit is
useful at all (vs float). A float can represent a max integer of 24 bits (23
digits of mantissa plus the "implied" MSB) so that max value is
  2^25-1 = 33,554,431,
which seems exactly the same as the LayoutUnit limit (see ToT
mouse-event-constructor.html).

I wasn't aware of the decision you mentioned about using floats for scroll
offsets, which seems quite logical now.

I will switch to FloatPoints then. Wdyt?

[bokan, 2016/11/15 15:26:00]

See crbug.com/470718 for the debate. LayoutPoint is useful in that we would
align better with page content since that's all positioned using the fixed
LayoutUnits. Although I think all existing scroll and event code uses floating
points so might as well keep that consistent for now. FloatPoint sgtm.

[mustaq, 2016/11/15 16:51:39]

Done.

I understand that the float vs Layout discussion has settled already but just
for future records:

My limit argument above seems off by a bit: float can represent 24 bits but that
means the max is 2^24-1 = 16777215, half of LayoutUnit limit.

+  DoublePoint m_layerLocation;
+  DoublePoint m_offsetLocation;
+  DoublePoint m_absoluteLocation;
   PositionType m_positionType;
   bool m_hasCachedRelativePosition;
 };
 
 }  // namespace blink
 
 #endif  // MouseRelatedEvent_h