1833963 - [pointer event] convert coordinates from long to double

Status: NEW

(Core :: DOM: UI Events & Focus Handling, enhancement)

Description

[Hsin-Yi Tsai (she/her) [:hsinyi]]

The current spec still defines "long" types for coordinates.

Filing this bug to track interests from web developers (see bug 1234669 comment 2) and the open spec issue https://github.com/w3c/uievents/issues/40.

Comment 1

[bplu4t2f]

Just want to add some additional context and a maybe unpleasant addendum here:

This is needed when a canvas in a high DPI setup is in play, that is, the canvas takes more physical device pixels than it does CSS pixels.
In that case, pointer events must be accurate to device pixels, otherwise some pixels are skipped in input processing, which results in apparent jagged motion when the input coordinates are used to render something in the canvas.

But that is not quite all.
See this discussion: https://github.com/KhronosGroup/WebGL/issues/2460
(there's a whole bunch of related issues mostly from the WebGL team)

Summary: Multiplying CSS pixel coordinates with the devicePixelRatio value will de facto produce off-by-one errors due to rounding issues, depending on circumstances. Any attempt to calculate the number of physical device pixels occupied by an arbitrary canvas given its bounds in CSS pixels, by using devicePixelRatio is doomed to fail with current browser implementations, and can lead to visible moire patterns in the canvas. This led to the creation of device-pixel-border-box in ResizeObserver, which gives the size in actual device pixels.

I am mentioning this because technically, pointer coordinates have a similar problem. Most code I've seen multiplies the pointer event coordinates with devicePixelRatio (I am not aware of any way to get raw device coordinates here - if there is, disregard this comment). As a user, given fractional pointer coordinates, and a fractional device pixel ratio, I would expect the resulting device pixel coordinate to be accurate within the limits of floating point arithmetic, and a rounding error should not occur in this order of magnitude.

Comment 2

[Hsin-Yi Tsai (she/her) [:hsinyi]]

This is being handled in bug 1680669 IIUC, while I am not sure if there's anything left even after bug 1680669 is done.