Created attachment 698584 [details] Canvas drawing test OS Version: 6.2 (Windows 8) Samsung ativ smart pc pro Firefox 17.0.1: Pen is slow Chrome 23.0.1271.97 m: Pen is slow IE 10: Pen is fast and responsive There is a lag (pen dragging delay) when drawing on a canvas with the s-pen in a Windows 8 tablet compared to a mouse. Drawing with IE10 works good. To reproduce, please open the attached test page and compare drawing with a wacom pen in Chrome to IE10 on a penabled Windows 8 tablet. In Chrome the pen is unresponsive and it's very hard to draw while in IE10 drawing is fast like with a native app. Windows 8 has several effects and features for a pen like Press-and-hold Dynamic Pen Feedback which are known to cause issues. Applications like Photoshop knows how to disable the features to make the pen more responsive. IE10 probably does the same. The following links might have usefull info: http://viziblr.squarespace.com/news/2012/8/18/windows-8-rtm-and-wacom-tablets-better-but-flawed.html http://viziblr.com/news/2012/12/21/a-possible-workaround-for-pen-dynamic-feedback-effects-and-w.html http://forum.wacom.eu/viewtopic.php?f=2&t=11674 http://msdn.microsoft.com/en-us/library/windows/desktop/hh924310%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/hh924309%28v=vs.85%29.aspx Thanks
Component: General → Widget: Win32
Product: Firefox → Core
Maybe posting a Gecko profile could help, see: - https://developer.mozilla.org/en-US/docs/Performance/Profiling_with_the_Built-in_Profiler - https://addons.mozilla.org/en-us/firefox/addon/gecko-profiler/
Please note that the delay only happens when pressing the pen onto the screen and starting to move it. After this delay time the pen draws with no delay. Lifting the pen off the screen and pressing it again starts with this initial delay. It makes it impossible to take notes or draw (you lift and press the pen rapidly). Photoshop Paint and IE10 don't have this delay but Firefox does. Is it possible to make Firefox work like IE10?
Please see the video in the link below that demonstrates the issue. In the first part the writing is fluid in IE 10. The last part shows that writing in Firefox 22 is hard, some lines are missing and trying to draw round paths results with straight lines. Tested on Samsung Galaxy ATIV Pro running Windows 8. https://docs.google.com/file/d/0B0odzw1WMqkGTTNKVVdQRnFkMVk/
FYI, this is a bug in the Wacom driver interacting w/ a misfeature in Windows 8 (which has native Touch support): http://forum.wacom.eu/viewtopic.php?p=45168 http://answers.microsoft.com/en-us/windows/forum/windows_8-hardware/windows-8-wacom-intuos-tablet-problems/b1d88c59-e495-46a0-b043-1bc2d63156cf
Reporter, can you test and confirm it's a bug with Wacom driver, please.
I only see the issue in Firefox and Chrome. IE 10 works great so it probably knows how to handle pen input better than Firefox. I also see the same issue on Galaxy Note 10.1 with Firefox mobile. Loic, how do you suggest testing the source of this issue?
(In reply to ofirr.dev from comment #6) > Loic, how do you suggest testing the source of this issue? Yes, the workaround proposed by Wacom in http://forum.wacom.eu/viewtopic.php?p=45168
None of the workarounds helps. The drivers are not relevant because the Samsung ATIV should use the Tablet PC driver.
If the Samsung ATIV runs Windows 8, the issue is the same. MS decided to prioritize the touch/swipe responsiveness at the expense of pen handling is how I understood all the Wacom responses I dug up. I can't explain why there are no problems w/ MSIE though and this issue is only w/ FF/Chrome though. That seems to indicate this isn't a Pen/Win8 issue if they figured out how to work around this :-P
I doubt this is the widget backend, seems more like it has to do with dom events perf.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Do you know if Mozilla has some hardware to test this issue?
(In reply to Loic from comment #11) > Do you know if Mozilla has some hardware to test this issue? Well we have a number of win8 tablets floating around. I personally did some testing on a surface pro and didn't really see much of an issue. If we can nail down specific hardware that really show the issue, if we don't have it we can purchase it. My guess is this would show up more on atom based tablets. I've got a acer atom on order at the moment which I should have in a few days.
I see the issue on the following hardware: - Samsung ATIV Smart PC Pro 700T http://www.samsung.com/us/computer/pcs/XE700T1C-A03US Windows 8 64bit Intel® Core™ i5-3317U 4GB Ram - Fujitsu T730 http://globalsp.ts.fujitsu.com/dmsp/Publications/public/ds-LIFEBOOK-T730.pdf Windows 8.1 64bit preview Intel® Core™ i5 M520 2.4GHz 6GB Ram
Created attachment 819897 [details] pen.html Test page for the distance from the mousedown event to the first mousemove event.
The above test page writes the distance from the mousedown event to the first mousemove event. Results from testing on Samsung ATIV Smart PC Pro 700T IE Mouse 1-5 pixels Pen 1-5 pixels FF Mouse 1-5 pixels Pen 30-60 pixels When using the S-Pen with FF we are getting the first mousemove event only after more than 30 pixels and that's the prof we have a lag when writing. A similar issue in FF for Android was fixed recently https://bugzilla.mozilla.org/show_bug.cgi?id=904245 There was a deliberate threshold that was meant to make sure a user is moving the finger instead of pressing but it is not needed for a pen which is much more accurate.
Still reproducible with FF 28 on Windows 8.1 Samsung ATIV Smart PC Pro Samsung ATIV Tab 3 It's possible that this issue is more problematic on Samsung's tablets than on the Surface Pro but I don't have it to verify. Can you please look at this issue again? Maybe as part of the pointer events implementation?
If a contributor would like to take a look, please do. I currently can't get to this but hopefully down the road we'll revisit touch input issues in desktop.
I played around with an otherwise-empty Win32 project (on a Samsung ATIV Tab 3) and found that the mousedown-mousemove distance can be fixed by handling the WM_POINTERUPDATE event as well as WM_MOUSEMOVE.
@reheated can you share the code that works for you?
Created attachment 8496755 [details] WM_POINTERUPDATE test (VS2013 project) It wasn't a very professionally done experiment. The attached VS2013 project is just a program which updates its window's title to the mouse coordinates whenever it gets a WM_MOUSEMOVE or WM_POINTERUPDATE. Press the "a" key to toggle ignoring WM_POINTERUPDATE - when I did this I experienced the "lag" between the mousedown and the next WM_MOUSEMOVE event. (I should have mentioned that for me the "lag" is only 7-12 pixels.)
I have the same lag problem with an external "trust" drawing tablet on Windows 7.
You need to log in before you can comment on or make changes to this bug.