Line Thickness Becomes Thicker When Drawing in the Bottom Part of the Viewer

[shun-iwasawa]

--Issue Summary--

Brush thickness becomes inconsistent in the bottom of the viewer.
Reported in the comment in #2005 by @openanim , also confirmed with my MobileStudioPro13.
This problem happens with all three types of level.

--Video or Image Reference--

GIF posted by @openanim

--Steps to reproduce--

• Select brush tool. Create and select any (Toonz Raster / Toonz Vector / Raster) type of level.
• Draw on the viewer with stylus.
• Compare the line drawn in the bottom of the viewer and in other part.

--Actual Results--

When drawing in the bottom of the viewer, line becomes thicker as if it fails to recognize pen pressure.

--Expected Results--

It should be drawn just like lines drawn in other part of the viewer.

--System Information--

• OpenToonz Version:

latest mater (2018-5-28)

• Operating System:

Win10

• Graphics Tablet:

MobileStudio Pro 13 (DTH-W1320)

---

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[manongjohn]

I am unable to duplicate this on the latest nightly. Could this be due to wacom tablets/drivers?

I recently switched to a larger xp-pen table and have a different issue where it randomly loses pen pressure when I start a new stroke.

[shun-iwasawa]

Could this be due to wacom tablets/drivers?

Probably, yes. It occurs only with my MobileStudioPro. On my desktop machine it works OK.

[ghost]

On some older versions the problem was not there. Here for example, I am on a version 1.1.3

[shun-iwasawa]

Although I still could not fix this issue, here are some findings:

• This problem occurs when the device pixel ratio is higher than 1 . With my Win7 desktop machine, this problem could be reproduced by setting Control Panel > Display > Make it easier to read what's on your screen to Large . OTOH this problem disappears when I set the display size to 100% on Mobile Studio Pro.

• This problem occurs only on Windows. On my MacBook Pro (which has high dpi display) this problem does not occur.

• This problem may be related to QOpenGLWidget . On @openanim 's advice I checked when this problem arose. I found that this problem firstly appears from 27 Oct. 2017, after introducing Fix for Shaders and Switch to QOpenGL by turtletooth and blackwarthog (modified) #1517 which is for transferring QGLWidget to QOpenGLWidget .

• The problem is due to SceneViewer fails to receive QEvent::TabletMove event for unknown reasons. In such case, SceneViewer receives only QEvent::MouseMove and act just like mouse dragging which ignores pen pressure. Oddly, observing TApp::eventFilter() the application DOES receive QEvent::TabletMove regardless of cursor position. The event seems to be lost somewhere before it is passed to SceneViewer.

Although this is critical, I stuck and decided to postpone this item. I'll try again after resolving other issues before releasing the next version. Hope someone will help solving this issue.

[manongjohn]

@shun-iwasawa i recently bought a new xp-pen tablet and noticed I was randomly losing pressure sensitivity when I started a stroke. I wasn't sure if it was the drivers or OT and did try to see if it was OT. My findings at the time seemed to be a driver issue. Apparently I was not quite looking at the full picture.

Based on your findings, the mention of the eventFilter and a lot of debug statents, i realize my issue was really OT and I believe its also the cause of this issue.

The problem is this: Normally the TabletPress event comes before the MousePress event. This order sets up some stuff so TableMove is processed and the MouseMove gets ignored.

The issue here i ls that randomly the MousePress comes before the TabletPress event. Apparently my tablet is more prone to doing that. In this case, the TabletPress fails to set something up to take over so the event gets thrown away and the mouse event is allowed to process, hence its stuck on full pressure.

I am currently working on trying to find the best fix for this.

[shun-iwasawa]

I'm not sure if it's related, but I found that the modification for adding Windows Ink API support to Qt is in progress. (QTBUG-60437 and the patch is under reviewing)
I'll check this issue again once the patch will be introduced.

[manongjohn]

Issue not resolved. Reopening.

[shun-iwasawa]

Sorry for not verifying it enough.
I checked again, and found that the pen seems to need to enter proximity on the viewer in order to make the pressure to work properly. If you enter proximity on another panel and then hover the pen into the viewer, the pen pressure does not work in the bottom part.
@openanim can you please confirm such behavior can be reproduced on your end?

[ghost]

the funny thing is I tested the original windows ink pr on my surface pro and it seemed to fix this

[manongjohn]

I did some testing and somehow this proximity issue appears to also impact #2220.

[ghost]

@shun-iwasawa If I understand correctly, yes I have a similar behavior. likewise on the whole right side of the viewer. However, I have no variation on the left.

[RodneyBaker]

I'm curious if users are still experiencing this problem.

[ghost]

Good point, at least on my side, I can't reproduce it anymore. Thanks.

[RodneyBaker]

Will close as you are the original presenter of the problem @openanim
If others are still experiencing the same or similar issues request that a new report be opened.
(I think there is at least one other similar report still open)