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

NEW
Unassigned

Status

()

P3
normal
6 years ago
2 years ago

People

(Reporter: ofirr.dev, Unassigned)

Tracking

17 Branch
x86_64
Windows 8
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: tpi:+)

Attachments

(3 attachments)

(Reporter)

Description

6 years ago
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

Updated

6 years ago
Attachment #698584 - Attachment mime type: text/plain → text/html
(Reporter)

Comment 2

6 years ago
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?
(Reporter)

Comment 3

6 years ago
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

5 years ago
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

5 years ago
Reporter, can you test and confirm it's a bug with Wacom driver, please.
Flags: needinfo?(ofirr.dev)
(Reporter)

Comment 6

5 years ago
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?
Flags: needinfo?(ofirr.dev)

Comment 7

5 years ago
(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
(Reporter)

Comment 8

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

Comment 9

5 years ago
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

Comment 11

5 years ago
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.
(Reporter)

Comment 13

5 years ago
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
(Reporter)

Comment 14

5 years ago
Created attachment 819897 [details]
pen.html

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

Comment 15

5 years ago
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.
(Reporter)

Comment 16

5 years ago
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?
Flags: needinfo?(jmathies)
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.
Flags: needinfo?(jmathies)

Comment 18

4 years ago
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.
(Reporter)

Comment 19

4 years ago
@reheated can you share the code that works for you?

Updated

4 years ago
Flags: needinfo?(reheated)

Comment 20

4 years ago
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.)
Flags: needinfo?(reheated)
I have the same lag problem with an external "trust" drawing tablet on Windows 7.
Whiteboard: tpi:?

Updated

2 years ago
Priority: -- → P3
Whiteboard: tpi:? → tpi:+
You need to log in before you can comment on or make changes to this bug.