Open Bug 827247 Opened 13 years ago Updated 10 days ago

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

Categories

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

Product:
Core
Component:
Widget: Win32
Version:
17 Branch
Platform:
x86_64
Windows 8
Type:
defect

Tracking

()

People

(Reporter: ofirr.dev, Unassigned)

Details

(Whiteboard: tpi:+ [win:touch])

Attachments

(3 files)

Canvas drawing test
4.08 KB, text/html
Details
pen.html
3.22 KB, text/html
Details
WM_POINTERUPDATE test (VS2013 project)
10.40 KB, application/zip
Details
Attached file 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
Attachment #698584 - Attachment mime type: text/plain → text/html
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/
Reporter, can you test and confirm it's a bug with Wacom driver, please.
Flags: needinfo?(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?
Flags: needinfo?(ofirr.dev)
(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
Attached file 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?
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)
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?
Flags: needinfo?(reheated)
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:?
Priority: -- → P3
Whiteboard: tpi:? → tpi:+
Severity: normal → S3

Back here 8 years later, I'm having this issue, with an XP-Pen tablet on Windows 10, on Firefox 126.0.1. Works fine on Edge and chromium browsers

Im unsure if it's the same bug, but the pen doesn't draw within a certain radius of when i put the pen down, but as soon as i start drawing it works fine.

I've updated my drivers to the latest and nothing changed.

Whiteboard: tpi:+ → tpi:+ [win:touch]

I also encountered this problem recently and have managed to investigate the root cause. With the current state of the codebase, it is not that the WM_POINTERUPDATE message is not handled, but rather there are two places within Firefox code that suppress dispatch of the pointermove events:

  1. widget\windows\nsWindow.cpp – OnPenPointerEvents: Initial pen movements smaller than SM_CXDRAG and SM_CYDRAG are suppressed to prevent resetting sLastMousePoint and sLastClickCount that are used for click tracking. However, when I inspect the remainder of the source file, sLastMousePoint does not seem to be affected by this and sLastClickCount has its own similar check to only reset when the movement is greater than the threshold.
  2. gfx\layers\apz\src\InputBlockState.cpp – UpdateSlopState: This function defines a "slop zone" that suppresses small touch movements. It ignores the presence of the touch-action CSS property.

I have attempted a patch that addresses those behaviors correspondingly as follows:

  1. Remove the small movement check when handling WM_POINTERUPDATE.
  2. Disable the slop zone if the touch-action value is none.

If there are no major issues with this, I would like to get this issue assigned and submit my patch.

Flags: needinfo?(cmartin)

Sorry about the delay -- I was hoping I would have time to review and test the patch before the year was up, but I didn't.

Will try to get to it later this year. This is almost-certainly going to require a non-trivial amount of manual testing because everything involving WM_POINTERXXX events is very complicated and can have all kinds of weird knock-on effects -- Especially around JS APIs.

Flags: needinfo?(cmartin)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: