ID 346731 - Nuke 11 Viewer lag on Linux when moving a Roto shape central to its control points, while having a Wacom installed

Problem summary
Nuke 11 exhibits a noticeable Viewer lag on Linux but not Windows and Mac, when moving a Roto shape from a central location between its shape control points. The same lag is not noticed when dragging the shape from closer to one of the shape points. (green highlighted point). The lag also only occurs on a machine that has a Wacom table connected, even if unused in Nuke.

​

This issue has only been reproduced on Linux machines and in Nuke 11 versions, but not in Nuke 10 versions. The cause of it appears to be related to a redraw call when the transform handle is used, as opposed to moving the shape by selecting all control points and moving any of those control points.

LATEST UPDATE

This bug has now been addressed in Nuke 11.1v4.
To take advantage of the fix, the QT_COMPRESS_TABLET_EVENTS environment variable needs to be set to 1 in the terminal from which Nuke is launched. For example:

export QT_COMPRESS_TABLET_EVENTS=1 

Please note that in order to always have Nuke launch with the environment variable set and use the fix, you need to include it in your Nuke launcher wrapper script.  Alternatively you can set the environment variable in the ~/.profile file by using the line above.
 

Customer reported version
nuke. 11.1v2

Customer reported platform
centos7

Steps to reproduce

1) launch Nuke 11.1v2 on a CentOS 7 machine (not reproduced on Windows or Mac OSX machines)
2) create a Roto node and a bezier shape
3) select the shape points and try moving the shape from the middle of its control points. A lag can be seen where the shape remains behind the cursor 
4) try grabbing the shape from closer to one of the shape's points and drag it. No lag is seen

Workaround
For Nuke versions prior to Nuke 11.1v4:
Either move the shape from closer to one of its control points, or create a Transform node and use its manipulators instead of the Roto node itself.  
Also, the issue only appears to happen when a Wacom tablet is connected, irrespective of whether the Wacom is used or just the mouse. Disconnecting the Wacom fully (uninstalling) has been reported to not exhibit the same lag behaviour when using Nuke. 

From Nuke 11.1v4: A fix has been implemented that requires the QT_COMPRESS_TABLET_EVENTS environment variable to be set to 1 in the terminal from which Nuke is launched. For example:

i.e. export QT_COMPRESS_TABLET_EVENTS=1 

Reproduced by support
Not reproduced by support.
Reproduced by customers on CentOS machines in Nuke 11.0 and 11.1.
Not reproduced by customers on CentoOS on Nuke 10, and not reproduced at all on Windows or Mac OSX. 

Expected behaviour
Moving a Roto shape should act the same no matter where the grab point is, and show no lag. 

Actual behaviour
Grabbing a Roto point from somewhere central to its control points shows a lag.