RE: Sub-pixel coordinate granularity

Wrong revision link below. Correct link:
https://dvcs.w3.org/hg/pointerevents/rev/36f85df11e83


From: Jacob Rossi
Sent: Monday, June 2, 2014 9:27 PM
To: Jacob Rossi; Rick Byers; public-pointer-events@w3.org
Cc: Simon Pieters
Subject: RE: Sub-pixel coordinate granularity

Given there seems to be consensus here, I’ve went ahead and made this change.  I did not change tilt as I haven’t seen devices that produce that type of resolution.  However, I fired off some mail to our pen experts to get their expert opinions—will report back to the group what I find.

https://dvcs.w3.org/hg/pointerevents/rev/cc1d34f697b3


-Jacob

From: Jacob Rossi [mailto:Jacob.Rossi@microsoft.com]
Sent: Friday, May 16, 2014 5:35 PM
To: Rick Byers; public-pointer-events@w3.org<mailto:public-pointer-events@w3.org>
Cc: Simon Pieters
Subject: RE: Sub-pixel coordinate granularity

LGTM – probably change tilt too while we’re at it? I think my tilt enabled device just gives integers, but I see no reason to restrict that. That said, tilt isn’t affected by zoom like width/height is.

From: Rick Byers [mailto:rbyers@google.com]
Sent: Friday, May 16, 2014 10:10 AM
To: public-pointer-events@w3.org<mailto:public-pointer-events@w3.org>; Jacob Rossi
Cc: Simon Pieters
Subject: Re: Sub-pixel coordinate granularity

We discussed this on a PEWG call at some point and agreed using floating point co-ordinates is a good thing, and that it happens in IE not just for browser zoom but also in high-dpi scenarios.

One thing we didn't discuss is what the right type for 'width' and 'height' are (which our spec DOES define).  If the co-ordinates are doubles then I'd argue 'width' and 'height' should be too, at least for consistency.  This is probably most important when zoomed in (but overall probably not that important for practical scenarios).  If we're making other normative changes, should we change this as well?

Rick

On Tue, Mar 18, 2014 at 4:29 PM, Rick Byers <rbyers@google.com<mailto:rbyers@google.com>> wrote:
Apparently IE returns sub-pixel co-ordinates for pointer events by default [1].  That blog post says that this only happens at browser zoom >100%, but shouldn't it also happen on high-DPI devices where 1 CSS pixel is larger than a screen pixel?  I don't have a high-DPI windows device to test currently.  Jacob/Asir, can you clarify IE's behavior here?

Also (tangentially related), that blog post indicates that there's web compat issues with having APIs like Element.scrollTop return fractional values (and so IE has a proprietary switch "msCSSOMElementFloatMetrics" for enabling it).  Simon Pieters (CSS OM Spec editor) asked for details on the web compat impact here [2] but never got any response.  Jacob, can you help get us some details from the IE team?

This is starting to become very important to us as in blink as we work to enable scroll-linked touch effects like pull-to-refresh on high-dpi devices.

Thanks,
   Rick

[1] http://blogs.msdn.com/b/ie/archive/2012/02/17/sub-pixel-rendering-and-the-css-object-model.aspx

[2] http://lists.w3.org/Archives/Public/www-style/2012Feb/1331.html


On Wed, Dec 18, 2013 at 12:13 AM, Rick Byers <rbyers@google.com<mailto:rbyers@google.com>> wrote:
Hi,
The latest CSSOM view editors draft extends a number of APIs (including MouseEvent) to use 'double' for co-ordinates instead of 'int' (http://dev.w3.org/csswg/cssom-view/#extensions-to-the-mouseevent-interface).  Since PointerEvent extends MouseEvent, we'd get this improved definition "for free".  I think this is valuable, for example, when implementing javscript-driven touch dragging or scrolling which should be just as smooth as native browser scrolling.

Thoughts?
   Rick