Input Mouse or Tablet events are too sparse when input device moves very fast in Windows #70765

Closed
opened 2019-10-12 20:26:03 +02:00 by Antonio Vazquez · 55 comments

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:

image.png

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.

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: ![image.png](https://archive.blender.org/developer/F7810571/image.png) 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.
Author
Member
Added subscribers: @pepe-school-land, @antoniov, @mendio, @WilliamReynish, @brecht

#70743 was marked as duplicate of this issue

#70743 was marked as duplicate of this issue
Author
Member

Copied from @brecht mail:

You'll need to dive into GHOST, and investigate what is happening there. Either the mouse events coming from the Windows API are not enough, or something goes wrong passing events from GHOST to Blender. If it's the former, search the Windows API documentation for information.

There's also old commits like this:
https://developer.blender.org/rB7aa8ae37819b4a95910089c27fa1e6d704a0f907

The situation might also be different for tablet and mouse.

Copied from @brecht mail: > You'll need to dive into GHOST, and investigate what is happening there. Either the mouse events coming from the Windows API are not enough, or something goes wrong passing events from GHOST to Blender. If it's the former, search the Windows API documentation for information. > > There's also old commits like this: > https://developer.blender.org/rB7aa8ae37819b4a95910089c27fa1e6d704a0f907 > > The situation might also be different for tablet and mouse. >
Author
Member

Added subscriber: @PabloDobarro

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.

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.
Author
Member

Test file, just open it and draw a curve very fast:

Mouse_Speed_Test.blend

Test file, just open it and draw a curve very fast: [Mouse_Speed_Test.blend](https://archive.blender.org/developer/F7810666/Mouse_Speed_Test.blend)
Author
Member

Added subscribers: @(Deleted), @CharlieJolly

Added subscribers: @(Deleted), @CharlieJolly
Author
Member

You'll need to dive into GHOST

I neved looked at that code before, so I will try, but not sure I will be able to fix/found the problem.

> You'll need to dive into GHOST 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.

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

Added subscriber: @dfelinto
Author
Member

I have been debug with Ghost and the events received in the operator.

==== Init =======
GHOST:Time:5250 (729,241)       MOUSEMOVE (729, 580)
GHOST:Time:5264 (720,241)       MOUSEMOVE (720, 580)
GHOST:Time:5272 (708,241)       MOUSEMOVE (708, 580)
GHOST:Time:5278 (687,242)       MOUSEMOVE (687, 579)
GHOST:Time:5288 (657,244)       MOUSEMOVE (657, 577)
GHOST:Time:5305 (572,245)       OTHER (572, 576)
GHOST:Time:5306 (516,252)       MOUSEMOVE (516, 569)
GHOST:Time:5321 (462,266)       MOUSEMOVE (462, 555)
GHOST:Time:5338 (370,290)       MOUSEMOVE (370, 531)
GHOST:Time:5355 (314,339)       MOUSEMOVE (314, 482)
GHOST:Time:5373 (301,380)       MOUSEMOVE (301, 441)
GHOST:Time:5388 (306,417)       MOUSEMOVE (306, 404)
GHOST:Time:5405 (330,446)       MOUSEMOVE (330, 375)
GHOST:Time:5421 (498,515)       MOUSEMOVE (498, 306)
GHOST:Time:5438 (670,529)       MOUSEMOVE (670, 292)
GHOST:Time:5455 (803,510)       MOUSEMOVE (803, 311)
GHOST:Time:5471 (830,499)       MOUSEMOVE (830, 322)
GHOST:Time:5488 (829,487)       MOUSEMOVE (829, 334)
======== End =======

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.

image.png

It looks the problem is in Ghost because it's not receiving all events.

I have been debug with Ghost and the events received in the operator. ``` ==== Init ======= GHOST:Time:5250 (729,241) MOUSEMOVE (729, 580) GHOST:Time:5264 (720,241) MOUSEMOVE (720, 580) GHOST:Time:5272 (708,241) MOUSEMOVE (708, 580) GHOST:Time:5278 (687,242) MOUSEMOVE (687, 579) GHOST:Time:5288 (657,244) MOUSEMOVE (657, 577) GHOST:Time:5305 (572,245) OTHER (572, 576) GHOST:Time:5306 (516,252) MOUSEMOVE (516, 569) GHOST:Time:5321 (462,266) MOUSEMOVE (462, 555) GHOST:Time:5338 (370,290) MOUSEMOVE (370, 531) GHOST:Time:5355 (314,339) MOUSEMOVE (314, 482) GHOST:Time:5373 (301,380) MOUSEMOVE (301, 441) GHOST:Time:5388 (306,417) MOUSEMOVE (306, 404) GHOST:Time:5405 (330,446) MOUSEMOVE (330, 375) GHOST:Time:5421 (498,515) MOUSEMOVE (498, 306) GHOST:Time:5438 (670,529) MOUSEMOVE (670, 292) GHOST:Time:5455 (803,510) MOUSEMOVE (803, 311) GHOST:Time:5471 (830,499) MOUSEMOVE (830, 322) GHOST:Time:5488 (829,487) MOUSEMOVE (829, 334) ======== End ======= ``` 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. ![image.png](https://archive.blender.org/developer/F7811171/image.png) It looks the problem is in Ghost because it's not receiving all events.
Member

Added subscriber: @LazyDodo

Added subscriber: @LazyDodo
Ray molenkamp self-assigned this 2019-10-12 23:49:23 +02:00
Member

This seems fun, mind if i take it?

This seems fun, mind if i take it?
Author
Member

@LazyDodo Sure!

@LazyDodo Sure!
Author
Member
Maybe this give us some ideas: * https://devblogs.microsoft.com/oldnewthing/20120314-00/?p=8103 * https://docs.microsoft.com/es-es/windows/win32/api/winuser/nf-winuser-getmousemovepointsex?redirectedfrom=MSDN
Author
Member

@LazyDodo I tested with these lines:

diff --git a/intern/ghost/intern/GHOST_EventCursor.h b/intern/ghost/intern/GHOST_EventCursor.h
index 7947b134f4b..ceff2249683 100644
--- a/intern/ghost/intern/GHOST_EventCursor.h
+++ b/intern/ghost/intern/GHOST_EventCursor.h
@@ -46,6 +46,7 @@ class GHOST_EventCursor : public GHOST_Event {
                     GHOST_TInt32 y)
       : GHOST_Event(msec, type, window)
   {
+    printf("GHOST:Time:%d (%d,%d)", msec, x, y);
     m_cursorEventData.x = x;
     m_cursorEventData.y = y;
     m_data = &m_cursorEventData;
diff --git a/source/blender/editors/gpencil/gpencil_paint.c b/source/blender/editors/gpencil/gpencil_paint.c
index f29e782c618..3649f00ae2b 100644
--- a/source/blender/editors/gpencil/gpencil_paint.c
+++ b/source/blender/editors/gpencil/gpencil_paint.c
@@ -2277,6 +2277,8 @@ static void gp_session_cleanup(tGPsdata *p)
 
 static void gp_session_free(tGPsdata *p)
 {
+  printf("======== End =======\n");
+
   if (p->rng != NULL) {
     BLI_rng_free(p->rng);
   }
@@ -3378,6 +3380,7 @@ static void gpencil_guide_event_handling(bContext *C,
 /* start of interactive drawing part of operator */
 static int gpencil_draw_invoke(bContext *C, wmOperator *op, const wmEvent *event)
 {
+  printf("==== Init =======\n");
   tGPsdata *p = NULL;
   Object *ob = CTX_data_active_object(C);
   bGPdata *gpd = (bGPdata *)ob->data;
@@ -3662,6 +3665,8 @@ static int gpencil_draw_modal(bContext *C, wmOperator *op, const wmEvent *event)
   GP_Sculpt_Guide *guide = &p->scene->toolsettings->gp_sculpt.guide;
   tGPspoint *points = (tGPspoint *)p->gpd->runtime.sbuffer;
 
+  printf(
+      "\t%s (%d, %d)\n", event->type == 4 ? "MOUSEMOVE" : "OTHER", event->mval[0], event->mval[1]);
   /* default exit state - pass through to support MMB view nav, etc. */
   int estate = OPERATOR_PASS_THROUGH;
 

@LazyDodo I tested with these lines: ``` diff --git a/intern/ghost/intern/GHOST_EventCursor.h b/intern/ghost/intern/GHOST_EventCursor.h index 7947b134f4b..ceff2249683 100644 --- a/intern/ghost/intern/GHOST_EventCursor.h +++ b/intern/ghost/intern/GHOST_EventCursor.h @@ -46,6 +46,7 @@ class GHOST_EventCursor : public GHOST_Event { GHOST_TInt32 y) : GHOST_Event(msec, type, window) { + printf("GHOST:Time:%d (%d,%d)", msec, x, y); m_cursorEventData.x = x; m_cursorEventData.y = y; m_data = &m_cursorEventData; diff --git a/source/blender/editors/gpencil/gpencil_paint.c b/source/blender/editors/gpencil/gpencil_paint.c index f29e782c618..3649f00ae2b 100644 --- a/source/blender/editors/gpencil/gpencil_paint.c +++ b/source/blender/editors/gpencil/gpencil_paint.c @@ -2277,6 +2277,8 @@ static void gp_session_cleanup(tGPsdata *p) static void gp_session_free(tGPsdata *p) { + printf("======== End =======\n"); + if (p->rng != NULL) { BLI_rng_free(p->rng); } @@ -3378,6 +3380,7 @@ static void gpencil_guide_event_handling(bContext *C, /* start of interactive drawing part of operator */ static int gpencil_draw_invoke(bContext *C, wmOperator *op, const wmEvent *event) { + printf("==== Init =======\n"); tGPsdata *p = NULL; Object *ob = CTX_data_active_object(C); bGPdata *gpd = (bGPdata *)ob->data; @@ -3662,6 +3665,8 @@ static int gpencil_draw_modal(bContext *C, wmOperator *op, const wmEvent *event) GP_Sculpt_Guide *guide = &p->scene->toolsettings->gp_sculpt.guide; tGPspoint *points = (tGPspoint *)p->gpd->runtime.sbuffer; + printf( + "\t%s (%d, %d)\n", event->type == 4 ? "MOUSEMOVE" : "OTHER", event->mval[0], event->mval[1]); /* default exit state - pass through to support MMB view nav, etc. */ int estate = OPERATOR_PASS_THROUGH; ```
Member

Added subscriber: @MikeErwin

Added subscriber: @MikeErwin
Antonio Vazquez changed title from Mouse events are too sparse when mouse moves very fast in Windows to Inpunt Mouse or Tablet events are too sparse when input device moves very fast in Windows 2019-10-13 11:44:47 +02:00
Antonio Vazquez changed title from Inpunt Mouse or Tablet events are too sparse when input device moves very fast in Windows to Input Mouse or Tablet events are too sparse when input device moves very fast in Windows 2019-10-13 11:45:52 +02:00
Author
Member

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

We 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.
Member

Do gimp or krita have the same issues? I’m wondering if they’ve solved the problem.

Do gimp or krita have the same issues? I’m wondering if they’ve solved the problem.

Added subscriber: @Xorrito

Added subscriber: @Xorrito

Clip Studio Paint for comparison on windows.
2019-10-13 15-33-06.mp4

Clip Studio Paint for comparison on windows. [2019-10-13 15-33-06.mp4](https://archive.blender.org/developer/F7814107/2019-10-13_15-33-06.mp4)

Added subscriber: @PrototypeNM1

Added subscriber: @PrototypeNM1
Author
Member

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.

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.
Ray molenkamp was unassigned by Antonio Vazquez 2019-10-14 08:44:53 +02:00
Antonio Vazquez self-assigned this 2019-10-14 08:44:53 +02:00
Author
Member

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

@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.
Author
Member

Adding the calculation of points of the missing arc, I get this (wip).
FastDrawingComparison.mp4

Adding the calculation of points of the missing arc, I get this (wip). [FastDrawingComparison.mp4](https://archive.blender.org/developer/F7816276/FastDrawingComparison.mp4)

Added subscriber: @s12a

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?

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

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.

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

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.

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

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.

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.
Author
Member

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.

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.
Author
Member

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.

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.

@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.
Author
Member

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

@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.
Member

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

@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.
Author
Member

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.

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

Those use bezier strokes. mapped with bitmaps and vector textures: Disney Meander, Moho ( Anime Studio), Toon Boom Harmony, CelAction

Added subscriber: @ArtemBataev

Added subscriber: @ArtemBataev

Added subscriber: @okuma_10

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.

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](https://archive.blender.org/developer/F7838509/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.
Author
Member

We have doing all changes in a separate branch, not in master.

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.

oldnewwintabwinink.png

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. ![oldnewwintabwinink.png](https://archive.blender.org/developer/F8184739/oldnewwintabwinink.png)

Added subscriber: @Pipeliner

Added subscriber: @Pipeliner
Author
Member

Changed status from 'Confirmed' to: 'Resolved'

Changed status from 'Confirmed' to: 'Resolved'
Author
Member

Fixed in 29f3af9527

Fixed in 29f3af952725

This issue was referenced by ea3e0b3e8c

This issue was referenced by ea3e0b3e8cbcf2768f2e8316addf554e06b888ee

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

Many issues with this, no pressure and not clicking. Check the video for more info [2020-04-08 23-27-48.mp4](https://archive.blender.org/developer/F8457823/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: d41d4d059332, 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?

@pepe-school-land Thank you for putting the video together. That's probably [D6675](https://archive.blender.org/developer/D6675), specifically hash ea3e0b3e8cbc 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)

More info: Works fine In commit a3c16055819f7236d0265dfa687f45031ee1b798 Don´t work well In commit ea3e0b3e8cbcf2768f2e8316addf554e06b888ee (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.

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

Just a friendly invitation for people testing things here to see the issue on #75546 - its culprint is allegedly d571d615a5.
Antonio Vazquez removed their assignment 2020-04-10 11:35:09 +02:00

Any news about this?

Any news about this?

@pepe-school-land
Some similar issues, #75653 and #75654, were reported and then merged into #75566.

@pepe-school-land Some similar issues, #75653 and #75654, were reported and then merged into #75566.
Sign in to join this conversation.
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
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
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#70765
No description provided.