Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Huion Linear Optimizer Issues #1133

scribblemaniac opened this Issue Nov 26, 2018 · 1 comment


None yet
2 participants
Copy link

scribblemaniac commented Nov 26, 2018

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:
Linear Optimizer option location
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. 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. 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 😮 💥
  • 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.

This comment has been minimized.

Copy link

CandyFace commented Dec 7, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.