PixarAnimationStudios / OpenUSD

Universal Scene Description

Home Page:http://www.openusd.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

usdview gui too slow when used with tablet/wacom

BSalem opened this issue · comments

Description of Issue

When using tablet (wacom) to tumble the viewport or scroll the prim browser or the prim data widgets, it's lagging a lot and responding to slow to drags.
While it's running very smooth and as expected when the interface is used by a regular mouse.

Note: With Python 3.7 (pyside2), only the viewport is slow to respond tablet drag, while with Python3.10 (PySide6) the whole GUI is not responsive/interactive (both working fine with mouse)

Steps to Reproduce

  1. Just try using a wacom with the interface.

System Information (OS, Hardware)

CentOS 8, NVidia RTX-2080Ti
Python3.10, PySide6

Package Versions

v24.05

Build Flags

Filed as internal issue #USD-9647

Apologies, @BSalem ... the majority of our GUI efforts go into Presto workflows, which uses PyQt, and that's where most of our tablet users are. We are also not on PySide6 internally at all, beyond basic MacOS testing. It's unlikely we'll be able to investigate this anytime soon.

Sounds good, actually I don't use pyside too, I had it installed just to have usdview gets compiled.
I will try to refactor it to use PyQt, then I believe the issues will get resolved (I couldn't find anything that leads to the issue at the first place, and it was always an issue since PySide2), in addition to that with pyside6, I had to deal with some keypress event issue in areas which didn't look like it's something wrong with the usdview code, but required additional checks to work as expected with pyside (I didn't report those as I believe it's related to a bug in PySide itself not the usdview)

Turning usdview to PyQt5 didn't make a difference when compared to PySide2.

It turned out that due to the tablet high precision, the mouseMoveEvent() loop is triggered dozes of times more than the case with a regular mouse move, then executing the tumble code and as many times as this resulted in very smooth but delayed viewport update.

preventing the mouseMoveEvent from being retriggered in less than 0.045 millisecond fixed the issue, and I'm able to get an interactive viewport that is still smoother than tumbling with the mouse, but without delayed update.

will submit a pull request for the fix though