Huion Linear Optimizer Issues

[scribblemaniac]

Many users have reported issues with Huion tablets. This issue will serve as a tracker for multiple different bugs from these complaints that I believe are all caused by the "Linear Optimizer" option in the HuionTablet app (possibly labeled "Enable Wintab Linear Optimization" on Windows). These issue include #877, #1110, and Difficulty with Tablet. I am able to reproduce these issues on my Huion H430P only when the Linear Optimizer option is enabled. Unless otherwise noted, these are all applicable to v0.6.2 and the November 9th 2018 nightly build. I have only been able to confirm that these issues occur on mac because the Windows application for my tablet does not have an option to enable the linear optimizer, and linux doesn't offer any options at all to my knowledge.

If you are experiencing similar problems to what is described below try disabling the option in the HuionTablet app under the Press Keys section: Not all Huion drivers expose this option unfortunately (including the H420), but hopeful we can find a fix for this.

Issue 1 – Extreme Lag

Extreme lag occurs when hovering over the tablet and when attempting to draw a stroke. Here is a video demonstrating the issue:

https://user-images.githubusercontent.com/2063777/135735596-147547ae-eb3d-494a-9c9e-39cbf3605251.mov

This issue is not a fixed delay, but rather a delay that increase the more you use the tablet, likely because Pencil2D is not processing events as fast as they are coming in, resulting in a buildup of events.

I built a program to measure the frequency of tablet events (I will open source it soon if you are interested in trying it yourself). It shows that my tablet as a peak rps/pps (reports per second/points per second) of 256. With the linear optimizer enabled, this doubles to 512. Subjective testing on Pencil2D suggests that this is an underestimate, possibly because of tracking events, which I have not yet been able to get working on my application.

Only counting unique tablet events (defined as events with a different event->posF() than the previous event) shows the same 256 rps with and without the linear optimizer. Unfortunately ignoring these events in scribblearea does not solve the problem.

Possible solutions for this include making the tablet move event processing faster and/or skipping events when the application is receiving more than it can process.

Issue 2 – Stroke Continues After Release

After the completion of a stroke, a full pressure line is drawn This issue is demonstrated in the video from Issue 1, that long straight line going off to the top right of the screen was not from drawing on the tablet. This final line appears to be drawn from the end of the stroke to the position of the cursor during its first movement after the application catches up. It does not matter if a mouse or tablet is used after the stroke, nor if the cursor leaves the canvas or not.

So far what I have noted pertaining to this issue is that in scribblearea.cpp after the tablet release event, there is a mouse move event followed by a mouse release event. In the mouse move event, the event reports that the left button is pressed. This occurs even if I do not touch the mouse.

This event occurs even if I unconditionally accept all tablet events at the very beginning of ScribbleArea::tabletEvent, so the mouse event should not be a result of Qt re-sending it as a mouse event.

Issue 3 – Displaced Strokes

At intervals, the stroke jumps from the place it is drawing on to a point further on in the path. It then goes back to its regular path. When it reaches the point it jumped to, it will be displaced again. Pressure is taken from the originating point, not the destination point. It gives the appearance of a second line being drawn, but is clearly not when you zoom in. Here is an example video:

https://user-images.githubusercontent.com/2063777/135735754-45274f58-b767-4fa3-8379-f59788c06a88.mov

There is always a stroke from the beginning to some point along the path, although it is very difficult to notice because the pressure is usually very low when you start drawing and I don't really want to stab my new tablet 😄

Possibly the events are arriving out of order? I still have to look into this issue more.

Issue 4 – Double Strokes

This is the only issue I have not been able to replicate yet, however it is clearly displayed in this video submitted by one of our users. Visually this is very similar to issue 3, however it can be differentiated by the fact that the long straight strokes are always full pressure. This issue may not be triggered by the linear optimizer option like the rest of these issues however it is so similar to other issues here that I thought I should include it. This was in v0.6.0, and I do not know if this issue persists on new versions.

Other Notes

• Strangely, during the recording of two of my demo videos here, one stroke worked perfectly and had no lag or other bugs. Subsequent strokes were laggy again as expected. This is a pretty rare occurrence and I don't what conditions cause this. Here is the full video for issue 3, showing the nearly identical first stroke working perfectly, followed by a few moments pause while I process what just happened 😮 💥

  https://user-images.githubusercontent.com/2063777/135735779-223399c5-ea33-43e8-90a8-c4d702034476.mov

• None of these issues appear in Krita, so we should probably look at what they do. Most of the relevant code is probably somewhere in here.

• Qt comes with a tablet example which I can replicate issues 1 and 3 with, so it may serve as a good minimal reference.

• v0.6.0 and v0.6.1.1 exhibit only issue 3. v0.6.2 exhibits issues 1 and 3. Locating the commit in which issue 1 was introduced may be informative.

• It is possible that some of these issues are not even Huion specific, but are only noticeable because of the large lag. All issues except for 1 could potentially go unnoticed if the brush was very fast. For instance, on older versions of Pencil2D that don't have the lag issue, issue 2 is only noticeable at fast speeds, and issue 2 either doesn't exist or is unnoticeable. If we fix issue 1 and some or all of these other issues go away, we should still locate the source of these issues.

[MrStevns]

Strangely, during the recording of two of my demo videos here, one stroke worked perfectly and had no lag or other bugs. Subsequent strokes were laggy again as expected. This is a pretty rare occurrence and I don't what conditions cause this.

Looking at the video makes me think that it the first stroke was done through mouse event and the latter through the expected tablet event thus having a lot more points and being much smoother in interpolation.

Qt's tablet recognizer is not flawless and will (based on my own experience) sometimes see your tablet as a mouse for reasons I'm not sure of yet.

[scribblemaniac]

This issue definitely needs to be revisited. If there is some kind of mixture of mouse and tablet events going on, it should be fixed by the reed issue workarounds (sub-issues 2 and 4). What I think is also promising is that we've had a lot less reports of issues with Huion tablets in say the past year. Potentially an update to Qt, the Huion drivers, or both has fixed some of these issues.

I'm going to assign this to myself just to retest the issues here that I could reproduce. If I can do that and identify if and when they were fixed, that would be very good progress on this.