827247 - Condiderable lag when drawing with a Wacom pen in a Windows 8 tablet

Status: NEW

(Core :: Widget: Win32, defect, P3)

Description

[ofirr.dev]

Attachment: 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

Comment 1

[Loic]

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/

Comment 2

[ofirr.dev]

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?

Comment 3

[ofirr.dev]

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/

Comment 4

[Ken Yee]

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

Comment 5

[Loic]

Reporter, can you test and confirm it's a bug with Wacom driver, please.

Comment 6

[ofirr.dev]

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?

Comment 7

[Loic]

(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

Comment 8

[ofirr.dev]

None of the workarounds helps.
The drivers are not relevant because the Samsung ATIV should use the Tablet PC driver.

Comment 9

[Ken Yee]

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

Comment 10

[Jim Mathies [:jimm]]

I doubt this is the widget backend, seems more like it has to do with dom events perf.

Comment 11

[Loic]

Do you know if Mozilla has some hardware to test this issue?

Comment 12

[Jim Mathies [:jimm]]

(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.

Comment 13

[ofirr.dev]

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

Comment 14

[ofirr.dev]

Attachment: pen.html

Test page for the distance from the mousedown event to the first mousemove event.

Comment 15

[ofirr.dev]

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.

Comment 16

[ofirr.dev]

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?

Comment 17

[Jim Mathies [:jimm]]

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.

Comment 18

[reheated]

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.

Comment 19

[ofirr.dev]

@reheated can you share the code that works for you?

Comment 20

[reheated]

Attachment: 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.)

Comment 21

[trondsg+bugzilla+mozilla]

I have the same lag problem with an external "trust" drawing tablet on Windows 7.