Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Huion Linear Optimizer Issues #1133
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:
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
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.
referenced this issue
Dec 4, 2018
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.