Various APIs are attempting to move to floating-point co-ordinates (eg. see bug 132895). Perhaps TouchEvent co-ordinates should also be float/double instead of long? http://trac.webkit.org/browser/trunk/Source/WebCore/dom/Touch.idl This may be valuable on high-dpi devices. Eg. if scrolling is happening in physical pixel units, it should be possible to build JS applications that move things around just as smoothly (as is possible in native iOS apps). Eg. imagine an app that does a custom pull effect when pulling down when the document is at scroll offset 0. Today when moving slowly this is noticeably jumpier on retina devices than the buttery smooth browser scrolling you get moving in the other direction. I'm in the process of switching blink to doubles: https://code.google.com/p/chromium/issues/detail?id=323935 The TouchEvents community group is also discussing this: http://lists.w3.org/Archives/Public/public-touchevents/2014May/0006.html
I agree, we should try this too. Do you have a test page where it is jumpy for reference?
Thanks! It can be pretty subtle in practice (especially if the finger is moving quickly), but here's an easy to visualize example: http://www.rbyers.net/paint.html#points - a drawing program that draws on physical pixel point per touchmove event. See https://code.google.com/p/chromium/issues/detail?id=323935#c34 for screenshots comparing integer to floating-point co-ordinates on a nexus 5 (which has DSF=3).
The difference is also pretty noticeable when dragging something around slowly. eg: http://jsbin.com/idojig/2/quiet
Assigning to Ben per #c1
Just wanted to ask if this was implemented already, and if not, if it in the works? Thanks!
<rdar://problem/24597318>
http://www.rbyers.net/paint.html#points is a compelling demo
Thanks Dean. The drawing example is easiest to visualize but is fairly niche. The really compelling scenarios IMHO are the dragging / custom scroll cases that are so common. Most such existing pages got noticeably smoother (when dragging slowly) when we shipped this in chromium.
Hi Dean, Is this planned for an upcoming release perhaps? Just wanted to get some updated info about this feature. Thanks.
<rdar://problem/9564176>
Created attachment 281273 [details] Patch
Created attachment 281277 [details] Patch
Attachment 281277 [details] did not pass style-queue: ERROR: Source/WebKit2/Shared/ios/NativeWebTouchEventIOS.mm:99: Comma should be at the beginning of the line in a member initialization list. [whitespace/init] [4] ERROR: Source/WebCore/ChangeLog:12: You should remove the 'No new tests' and either add and list tests, or explain why no new tests were possible. [changelog/nonewtests] [5] Total errors found: 2 in 17 files If any of these errors are false positives, please file a bug against check-webkit-style.
Comment on attachment 281277 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=281277&action=review > Source/WebCore/platform/Widget.cpp:144 > + if (!windowFraction.isEmpty()) { > + const int kFactor = 1000; > + IntPoint parentLineEnd = this->convertFromContainingWindow(flooredPoint + roundedIntSize(windowFraction.scaledBy(kFactor))); > + FloatSize parentFraction = (parentLineEnd - parentPoint).scaledBy(1.0f / kFactor); > + parentPoint.move(parentFraction); > + } Any way to change convertFromContainingWindow() to handle floating point coordinates instead? Linear interpolation of the decimal part is only gonna work for a small subset of transforms. > Source/WebKit2/UIProcess/WebPageProxy.cpp:1944 > + TrackingType touchPointTrackingType = m_scrollingCoordinatorProxy->eventTrackingTypeForPoint(roundedIntPoint(touchPoint.location())); This is unfortunate. I don't know how complicated it would be to add Region::contains() for FloatPoint.
(In reply to comment #14) > Comment on attachment 281277 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=281277&action=review > > > Source/WebCore/platform/Widget.cpp:144 > > + if (!windowFraction.isEmpty()) { > > + const int kFactor = 1000; > > + IntPoint parentLineEnd = this->convertFromContainingWindow(flooredPoint + roundedIntSize(windowFraction.scaledBy(kFactor))); > > + FloatSize parentFraction = (parentLineEnd - parentPoint).scaledBy(1.0f / kFactor); > > + parentPoint.move(parentFraction); > > + } > > Any way to change convertFromContainingWindow() to handle floating point > coordinates instead? We would have to change quite a few methods, but I don't see why we couldn't. I'm not certain this is warranted though. > > Source/WebKit2/UIProcess/WebPageProxy.cpp:1944 > > + TrackingType touchPointTrackingType = m_scrollingCoordinatorProxy->eventTrackingTypeForPoint(roundedIntPoint(touchPoint.location())); > > This is unfortunate. > I don't know how complicated it would be to add Region::contains() for > FloatPoint. I think we could change the signature of Region::contains(const IntPoint& point) to take in a FloatPoint and operate on float values instead. I'll look into this.
(In reply to comment #15) > (In reply to comment #14) > > Comment on attachment 281277 [details] > > Patch > > > > View in context: > > https://bugs.webkit.org/attachment.cgi?id=281277&action=review > > > > > Source/WebCore/platform/Widget.cpp:144 > > > + if (!windowFraction.isEmpty()) { > > > + const int kFactor = 1000; > > > + IntPoint parentLineEnd = this->convertFromContainingWindow(flooredPoint + roundedIntSize(windowFraction.scaledBy(kFactor))); > > > + FloatSize parentFraction = (parentLineEnd - parentPoint).scaledBy(1.0f / kFactor); > > > + parentPoint.move(parentFraction); > > > + } > > > > Any way to change convertFromContainingWindow() to handle floating point > > coordinates instead? > > We would have to change quite a few methods, but I don't see why we > couldn't. I'm not certain this is warranted though. FWIW I felt really dirty doing this linear interpolation hack in blink (and left myself a FIXME to clean it up) but honestly after 2 years I haven't heard of a single example of anyone noticing it being less than perfect in the edge cases (rotated iframes mainly I guess). I started to go down the path of fully supporting float but it exploded into a ton of work so I put it off. I assumed we'd have other reasons to want fractional co-ordinate conversion between widgets but it's never come up since. Maybe that was the wrong decision though - certainly feels wrong.
Hey Guys, I'm trying to use the apple pencil on an iPad pro with canvas to replace native apps, this is when I realized that the Touch.clientX and clientY are quantized to integers. Floating point would be very important for this application! and I think using apple pencil to draw on iPad pros is going to be a common thing to do in the future. It would be a shame if we can't do this properly in the browser. Thanks for all of the work! Ge
Comment on attachment 281277 [details] Patch r-, as this has been pending review for over a year now. It is near-impossible that this patch still applies to trunk and unlikely to still be relevant in its current form.
I was wondering if there had been any progress addressing this bug. The lack of sub-pixel accuracy in touch events severely limits the capabilities of web-based drawing applications, and to my knowledge, there are no workarounds.
the workaround, in future, would be to use Pointer Events (supported for the most part in Safari 13 onwards) rather than Touch Events https://w3c.github.io/pointerevents/
Any progress on this issue ? Still touch events became with large numbers in 2020.
Someone needs to research if this is already addressed by Pointer Events. If it is, we'll likely mark this issue as WONTFIX because Pointer Events supersede Touch Events in every way. If it's not, then we need to reassess this in the context of Pointer Events.
I adjusted one of the demos to use Pointer Events at https://output.jsbin.com/hecifuweta/1. The issue is still relevant, we're still ending with integer values.
This has not been addressed for PointerEvent. I've tested Safari 14.1 on a retina MacBook Pro and looked at pointermove events fired using `document.onpointermove = console.log` (on any page). The events have only integer coordinates. This can also be seen directly in the IDL files. The coordinates in question are inherited from MouseEvent, and they're still of type long: https://github.com/WebKit/WebKit/blob/9940f5c6cd901c3cce4efb372ebd94d808218d80/Source/WebCore/dom/MouseEvent.idl#L29-L32
on latest iOS 15 (GM?) both touch and pointer events are still integers on my iPad
Any update about this? Scroll events also have this problem.
This is a major issue for webview-based iOS apps. Please, please fix it...
Hey, any updates on this? As mentioned before, it's a bit of a headache for apps using WebView. The impact is pretty noticeable, especially on devices with DPI > 1. It's making animations and canvas work feel laggy, which isn't great for user experience. Any chance we could address this soon?
(In reply to Fabian from comment #28) > Hey, any updates on this? As mentioned before, it's a bit of a headache for > apps using WebView. The impact is pretty noticeable, especially on devices > with DPI > 1. It's making animations and canvas work feel laggy, which isn't > great for user experience. Any chance we could address this soon? Have you tried this on latest Safari? Maybe create a Safari Fork and listen touch events directly from Native iOS listener? :D Because iOS Listener pass pointer information very accurate, the only need to grab it on Safari. For example, in Cordova can be created a special plugin that will be used only Device Pointer events value instead of Safari.
(In reply to Roman A. from comment #29) > (In reply to Fabian from comment #28) > > Hey, any updates on this? As mentioned before, it's a bit of a headache for > > apps using WebView. The impact is pretty noticeable, especially on devices > > with DPI > 1. It's making animations and canvas work feel laggy, which isn't > > great for user experience. Any chance we could address this soon? > > Have you tried this on latest Safari? Maybe create a Safari Fork and listen > touch events directly from Native iOS listener? :D > Because iOS Listener pass pointer information very accurate, the only need > to grab it on Safari. > For example, in Cordova can be created a special plugin that will be used > only Device Pointer events value instead of Safari. This issue persists for both touch and pointer events. In my opinion, the solution shouldn't involve merely intercepting native gestures on a WebView, which, by the way, isn't a reliable approach, especially on iOS where UIWebView doesn't interact well with gesture recognizers. Resorting to such a method would be a hacky workaround. Instead, addressing the root cause directly would be more effective. Even if we were to implement a fix using Cordova or Capacitor Plugins, the underlying issue would remain unaddressed on the web platform. The problem isn't with pointer events (or touch events) being inherently inaccurate. They function perfectly well on devices with a DPI of 1. However, devices with higher DPI, like iPads with Retina Displays boasting a DPI of 2, encounter issues. Despite having double the pixel density, touch or pointer events still report coordinates with the same pixel accuracy as devices with a DPI of 1. Native gestures handle this disparity appropriately. For instance, on an iPad, values are doubled to accommodate the higher DPI (e.g., you'd receive values like 0.5). However, Safari fails to implement this behavior. Instead, it only provides whole integer values. Consequently, animations appear less fluid on high-DPI devices, as they miss out on finer pixel-level movements, resulting in perceptible micro-jumps. What baffles me is that this isn't a technical limitation but rather an implementation choice. It's puzzling why Safari doesn't forward the accurate coordinate values. Restricting them to integers seems unnecessary and counterproductive.