Input Mouse or Tablet events are too sparse when input device moves very fast in Windows #70765
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
18 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#70765
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Basically, the problem we have detected is the mouse/pen events are missing when you move the mouse very fast. We have checked all the events in
wm_event_add_mousemove()
function and if you move very fast, you get only a fraction of the mouse positions. We have tested in Linux and Windows and the problem is mainly in Windows.This is not a problem specific to 2.8x, it’s a general problem in all versions.
Example image:
In the image above, I tried to draw a curve very fast with the mouse (artists draw these curves very fast to get gesture drawing)… as you can see, the distance increases when the mouse moved fast (in the curve section). Of course, we tested MOUSEMOVE and INBETWEEN_MOUSEMOVE events, but the problem is we never received an INBETWEEN_MOUSEMOVE event. The tested operator is using OPTYPE_BLOCKING flag.
For other tools to have all events is a nightmare, but for drawing in grease pencil this is critical. We have added a lot of tricks to smooth and try to simulate the missing events and we get a reasonable result, but the “real” solution is to get the events because any method used always “change” slightly the artist gesture.
@pepe-school-land was testing and Linux hasn’t this problem or is less noticeable, and the “feeling” is better in that OS.
Added subscribers: @pepe-school-land, @antoniov, @mendio, @WilliamReynish, @brecht
#70743 was marked as duplicate of this issue
Copied from @brecht mail:
Added subscriber: @PabloDobarro
Yes, the diference between windows and linux is sooo huge in Blender in fast drawing movements.
In windows is a real issue have this poor perfomace in Blender for fast drawing movements.
Test file, just open it and draw a curve very fast:
Mouse_Speed_Test.blend
Added subscribers: @(Deleted), @CharlieJolly
I neved looked at that code before, so I will try, but not sure I will be able to fix/found the problem.
On macOS via Sidecar, developers can get access to the raw Apple Pencil data, which is recorded at 256hz (!), That should really help produce very smooth lines.
Added subscriber: @dfelinto
I have been debug with Ghost and the events received in the operator.
All the events of Ghost (first column) are passed to the operator as events (2nd column). There are 18 events in Ghost and the same in the operator, and this is the resulted stroke with 18 points.
You can see the big gap between point 13th and 14th (330,446) and (498, 515).
Note: The diference in coords values is due the conversion done by event system to produce window coordinates.
It looks the problem is in Ghost because it's not receiving all events.
Added subscriber: @LazyDodo
This seems fun, mind if i take it?
@LazyDodo Sure!
Maybe this give us some ideas:
@LazyDodo I tested with these lines:
Added subscriber: @MikeErwin
Mouse events are too sparse when mouse moves very fast in Windowsto Inpunt Mouse or Tablet events are too sparse when input device moves very fast in WindowsInpunt Mouse or Tablet events are too sparse when input device moves very fast in Windowsto Input Mouse or Tablet events are too sparse when input device moves very fast in WindowsWe have been testing several options and even MS-Paint has the same problem. I'm thinking that maybe the solution is not at event side, but to generate a Bezier in the segments to get a smooth transition. Using Bezier, we keep event system, don't overpopulate events and get the same result in all OS's. I need to think, but I have a rough idea already.
Do gimp or krita have the same issues? I’m wondering if they’ve solved the problem.
Added subscriber: @Xorrito
Clip Studio Paint for comparison on windows.
2019-10-13 15-33-06.mp4
Added subscriber: @PrototypeNM1
It looks Clip Studio is doing the conversion to Bezier as Disney Meander does: https://www.disneyanimation.com/technology/innovations/meander
I will try to convert on the fly the stroke to Bezier and I hope to get very smooth strokes without ugly steps.
@LazyDodo I take the task to work in the Bezier idea inside grease pencil drawing operator, but you can investigate in the events system to check if we can improve in that area too.
Adding the calculation of points of the missing arc, I get this (wip).
FastDrawingComparison.mp4
Added subscriber: @s12a
Most 2D painting programs use pen tablet events from the pen tablet driver (e.g. wintab) instead of OS mouse cursor events for pointer position. This also allows subpixel precision and better accuracy. Perhaps this is where the problem lies?
Added subscriber: @ciriaco
I am sorry to insist so much, but the brake on the professional use of grease pencil in 2D animation is a design concept: the use of poly lines instead of splines. IMHO I think it would take a breakcoffe to redesign the GP evolution strategy.
Thanks for your great work.
Added subscriber: @n1729
Grease Pencil's sculpt tools are superior to other products.
I suppose the use of poly lines gives the feature of sculpting (and also animation) an advantage.
I think @s12a is right. I don't think any other drawing application is using Beziers to generate samples from mouse events. Last year I had a problem with Photoshop, it was producing lines with artifacts the same way Grease Pencil does. It has a configuration file where you can change the pen input device to the tablet driver, and that solved the problem. That said, we should probably keep the bezier interpolation in case that a tablet device is not available.
This is what I'm doing. The arc ppoints are only created if the device is not able to provide it. In some OS's and/or deviced we get the "real" events data and don't need to create these missing points.
And It is not entirely correct that no application uses conversion to curves. Disney Meander, used to create Paperman shortfilm, used these techniques to get a very smooth strokes converting the mouse/pen movement to curves. We tested to use raw data from the device and the UI gets unstable because we are not reading this data directly but using all Blender operator system, so add raw data to GHOST is not only for this, but for all UI also and this is not good idea.
@antoniov
For what it's worth, I have a Wacom Intuos5 L with the latest drivers on Windows 10, and on the latest Blender build, as well as all other previous builds, It doesn't appear that subpixel precision from the tablet driver is used. This is most apparent when removing stroke post-processing and smoothing options and attempting to write cursive text in very small size.
With a 2D painting program like Krita if I zoom back, write small text (also without stroke smoothing options enabled), then zoom in again, the text is readable. If I repeat the same test with Grease pencil on Blender, it looks as if it got constrained to the visible screen pixel grid. From this I assumed that raw mouse cursor events from the OS are used instead of coordinates and events from the tablet driver. Explicitly selecting WinTab/Windows Ink in program option makes no difference.
@s12a you miss one point... all what you do in 2D is converted to 3D, so the limitation to pixels is not only due the device. I don't say it's not possible to do, but if we have to rewrite a lot of code, then it's out of scope now, and make comparison between Krita and Blender is not totally correct because their approach are totally different.. Grease Pencil is for animation, Krita is for drawing and painting pixels. I don't think we can get in Blender a tool for painting as Krita never.
@antoniov But why are we not using screen subpixel precision from the tabled driver? It is going to be more noticeable in Grease Pencil, where the final data is not constrained by a pixel grid. Also, 2D paint now supports floating point precision in the brush position, so it will also benefit from that. I don't think we need to change anything in Blender tools to support that.
The mouse / pen event management is the code of the old 2.7x and I suppose that to use the sub-pixel, you must use float instead of ints, so this would require refactoring all the code using sbuffer strokes and any function related to that, To use this data we will need time to change that I don't have (or don't want to use in this) ... I think there are other areas more important than this.
And the question here is whether we will obtain a notable difference that is worthwhile for all these changes because the problem was not the accuracy, but the missing events when you move very fast.
Those use bezier strokes. mapped with bitmaps and vector textures:
Disney Meander, Moho ( Anime Studio), Toon Boom Harmony, CelAction
Added subscriber: @ArtemBataev
Added subscriber: @okuma_10
sorry to intrude.But I downloaded the blender 2.82 release from yesterday and I see the same issue.Here is some example:
2019-10-19 17-38-20.mp4
Back when I started using grease pencil, I had an issue with attaching lazy nezumi to it. After some back and forth, the LN developer found some issue in his code. But he did mention that he wanted to write a guide for software developers on how to properly use the tablet drivers(wintab/windows ink). Maybe you guys can contact him if not already and collaborate on bringing direct tablet input.
We have doing all changes in a separate branch, not in master.
Comparison of 2.80 tablet input vs a wip coalesced pointers.
Note: I think the red circled point in Old Win Ink is an unreported bug resolved in the New Win Ink code.
Added subscriber: @Pipeliner
Changed status from 'Confirmed' to: 'Resolved'
Fixed in
29f3af9527
This issue was referenced by
ea3e0b3e8c
Many issues with this, no pressure and not clicking.
Check the video for more info
2020-04-08 23-27-48.mp4
Info:
Huion Kamvas Pro 22 (2019)
Blender 2.83 (sub 13), branch: master, commit date: 2020-04-08 17:03, hash:
d41d4d0593
, type:build date: 2020-04-08, 18:29:54
platform: Windows
@pepe-school-land Thank you for putting the video together.
That's probably D6675, specifically hash
ea3e0b3e8c
where Wintab code is largely rewritten. If you could check that commit and the one prior it would help narrow things down.I'll put together logging code to narrow down the problem with Wintab; expect a build in the next day or so to test.
I suspect Windows Ink has no pressure because your Huion preferences utility doesn't have Windows Ink enabled, could you check for that?
More info:
Works fine In commit
a3c1605581
Don´t work well In commit
ea3e0b3e8c
(the issuses from the video in the previous post)
@pepe-school-land, we're aware that this is the range of commits where changes happened. What @PrototypeNM1 was asking about is which commit in that range caused the problem. In particular, if
d571d615a5
has the problem.@PrototypeNM1, also Wintab problems reported in #68496 (Hardware: Tablets: Problem with Trust Panora Widescreen graphic tablet ).
Hopefully we can resolve this for 2.83, but if not at least the Wintab changes can move to 2.90.
Just a friendly invitation for people testing things here to see the issue on #75546 - its culprint is allegedly
d571d615a5
.Any news about this?
@pepe-school-land
Some similar issues, #75653 and #75654, were reported and then merged into #75566.