Bad pen trail performance

[DanielBrosch]

The performance seems to go down significantly (updates maybe 1-2 times a second) when hovering with the pen (and the CPU usage hovers around 80%). I am using settings "pen_size": 30, "pen_color": "red", "pen_trail": 200. This even happens if pen_trail is zero (i.e. if I just want to see a red dot).

While writing (without pen trail) the viewer updates much smoother.

[bordaigorl]

I need more info: Os, RM1 or RM2?
What exactly do you mean by "updates": do you mean the screen update or the pen tracking position update?
Typically the pen trail is displayed when no update of the screen is happening.
Can you describe your specific use case to reproduce the issue?

[DanielBrosch]

Windows 10, RM2

To clarify: I want to use this tool for giving presentations. So I sometimes want to hover the pen over the screen, highlighting part of some slides, without actually writing on them.

Right now if I do that the pen trail looks pretty laggy, and only updates about twice a second while moving. It actually does seem to get worse the longer you hover (after about 5-10 seconds it only updates once a second).

[bordaigorl]

Ok that's strange.
Is there any combination of settings that resolves the issue?
Are you connecting via USB or WiFi?
Are you testing this while using other software that may be affecting performance?
For example: OBS, screen capturing apps, or something network heavy while connecting via Wifi.
Does the issue persist if you close all other apps?

[bordaigorl]

(One thing that could help is removing line 337 from rmview.py)

[DanielBrosch]

I so far nothing I tried resolved it. I connected the tablet via USB. The problem persists even if everything else is closed.

I captured the problem: (Note that here the performance is worse by a factor of about 2-3 due to screencapturing)

PenPerformance.mp4

[DanielBrosch]

(One thing that could help is removing line 337 from rmview.py)

I already added
if self.trailDelay > 0:
there, which does make it much smoother. But then I loose out on the pen trail, of course.

Also, every time I close the program (using right click->quit), I get

Stopping framebuffer thread...
Connection lost: Connection to the other side was lost in a non-clean fashion: Connection lost.
Framebuffer thread stopped

[bordaigorl]

I already added
if self.trailDelay > 0:
there, which does make it much smoother. But then I loose out on the pen trail, of course.

That does not seem right: if trailDelay is 0 then trail is None so that code should not be executed anyway.

Can you try by just removing QTimer.singleShot(self.trailDelay // 2, lambda: t.setOpacity(.5)) altogether?
It could be that the QTimer events are clogging the event queue, or that the opacity is a performance bottleneck on Windows (just guessing)

[DanielBrosch]

I already added
if self.trailDelay > 0:
there, which does make it much smoother. But then I loose out on the pen trail, of course.

That does not seem right: if trailDelay is 0 then trail is None so that code should not be executed anyway.

Oh, sorry, you are right of course, no performance difference.

Can you try by just removing QTimer.singleShot(self.trailDelay // 2, lambda: t.setOpacity(.5)) altogether?
It could be that the QTimer events are clogging the event queue, or that the opacity is a performance bottleneck on Windows (just guessing)

The performance is still bad, but may be slightly better. It seems to get worse the bigger the window is. Landscape full screen size (1080p) performance is not very usuable with pen trails. (General update rate also seems to go down a notch, but not as bad as the pen trails. Small window looks pretty much instant, full screen still fast, but visible steps.)

[bordaigorl]

Oh no that sucks, I am sorry!
I am not sure what may be causing this (I cannot reproduce, but I may try later on a windows machine) could be some performance issue between Qt and the graphics card? Shooting in the dark here...which machine are you using?

[bordaigorl]

One fleeble idea: add self.setViewportUpdateMode(QGraphicsView.BoundingRectViewportUpdate) at line 14 of viewer.py.

[DanielBrosch]

I am not sure what may be causing this (I cannot reproduce, but I may try later on a windows machine) could be some performance issue between Qt and the graphics card? Shooting in the dark here...which machine are you using?

I am currently using the Laptop Acer Aspire F5-573G. Processor: Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz, 2701 Mhz, 2 Core(s), 4 Logical Processor(s), GPU NVIDIA GeForce 940MX.

I just noticed that rmview for some reason only uses the integrated GPU and not the dedicated one. Investigating now why. Could be that I set some too strong battery saving options years ago when I used this laptop more on battery....

[DanielBrosch]

Actually, it doesn't use either GPU, it seems to run CPU based. Both stay at under 2-3% while the CPU jumps to >80% when something is drawn.

One fleeble idea: add self.setViewportUpdateMode(QGraphicsView.BoundingRectViewportUpdate) at line 14 of viewer.py.

Also, this does not seem to change anything.

[DanielBrosch]

I tried to enforce GPU use with the NVIDIA control panel for rmview.exe (and system wide default), but it does still only use the CPU.

[bordaigorl]

Are you using the windows bundle from the releases?
If so you could try and install rmview with the other method.

[DanielBrosch]

I cloned the repository and followed the pip install instructions. I just tried out the windows bundle, too, and have the same thing there: Bad pen trail performance, and no GPU use.

[bordaigorl]

Thanks for testing that. One thing I would try is to see if the python executable was allowed to use the GPU.

[DanielBrosch]

I already did set it up in NVIDIA control panel for both the python and rmview executables. Is there another place to check?