flxzt
Lagging after a few strokes on Mac
Describe the bug
After a few strokes drawn (~300), Rnote appears to be lagging severely. I can see CPU overload by profiling, but cannot find a clear hotspot. Different from previous issues, this can be fixed by reopening the document. So I guess it's related to something that would accumulated with strokes in one session.
To Reproduce
Steps to reproduce the behavior:
- Launch Rnote and keep drawing.
- 3 minutes later, everything is lagging, can't write fluently
- Save the document, close Rnote and reopen the file. Everything back to normal until a few strokes written and this happens again.
Expected behavior
Keep fluent for a long time.
Console Output
todo
Screenshots
Desktop (please complete the following information):
- OS: macOS 15.7.2
- App Version: Rnote v0.13.1
- Installation Source: download dmg from gitlab releases
- Input Source: External Graphics Tablet (Gaoman 1060pro)
Additional context
Add any other context about the problem here.
That may be #1436 (and so would be fixed by #1462) but I'm not 100 % sure if that included the fact that this is fixed after a restart. The dependence on the number of strokes (and why that happens) was identified.
For the restart part, not sure of the reason (maybe the rtree is more balanced when rebuilt vs inserting strokes in the order of the page continuously?)
That may be #1436 (and so would be fixed by #1462) but I'm not 100 % sure if that included the fact that this is fixed after a restart. The dependence on the number of strokes (and why that happens) was identified.
For the restart part, not sure of the reason (maybe the rtree is more balanced when rebuilt vs inserting strokes in the order of the page continuously?)
Just read through that issue, sorry for not reading it in detail before. The lagging looks similar to my case, which does have some input lost. I can reproduce it easily in minutes by drawing randomly on canvas, and can be fix by a restart, slightly different from that needing pages to reproduce.
Thank you for your contribution to performance issue. I tried to build Rnote with branch Doublonmousse:performance at commit 5efa8e2b. But the issue persists in my case. Although I am not good at anything here, I would try some debug techniques in the previous issue to see if I can find more useful information.
I use Rnote on another machine running linux. But I haven't seen such performance degradation before. So it could be platform related. Though it's not quite fair as my Mac is less powerful. I would perf Rnote on linux and compare the flame graphs later.
My tablet driver crashed for times during the test, which looks suspicious to me as well. But I tried krita and it went well. So maybe the degradation is not caused by driver.
The whole profile is large. I capture the Heaviest Stack Trace in the last minutes. I can see an increment in some gtk event stuff, but have no idea what it means. As for the restart, I found that just reopen the file can fix it. Here I have 2 samples generated by cargo-flame graph. sample1 is when Rnote went slow and sample2 is when I reopened the file and did the same thing before getting slow.
Mh ... Yeah it's not clear from this. The hard part is that the lag may not necessarily come from where the most time is spent.
As long as your event loop function don't take more than a frame time to finish processing (and displaying the result) you won't see the lag. But if you spend 1 second in that loop for a single event you'll get 1 fps.
The most I can say is that comparatively, more time is spent in gdk_macos_event_source_dispatch (which is part of the event system).
The gpu-related part is the gsk_gpu_* functions but they don't seem to be using that much.
I can't see rust/rnote function in here, though I know that gtk_event_controller_legacy_handle_event (3,816 samples, 8.80%) corresponds to handle_pointer_controller_event in rnote-ui/src/canvas/input.rs.
Though the place gdk_macos_device_set_surface_cursor seems quite insane, so there's probably something here that doesn't work well (I'm going to check that first, this may not be the reason but it's kinda bugging me out)
Last thing, maybe follow https://blogs.gnome.org/haeckerfelix/2023/12/03/profiling-rust-applications-with-sysprof/ and compile with force-frame-pointers=yes (https://doc.rust-lang.org/rustc/codegen-options/index.html#force-frame-pointers) so that rust function calls are shown.
sysprof is not viable on Mac unless I install Linux. I tried it on Linux and get a similar call stack with tons of gtk stuffs. I used instruments with dSYM and saw Rnote functions till run_with_args. I don't know gtk but maybe most Rnote functions are called by gtk in a callback style, and so it cannot be recognized by profiler? Anyway, profiling seems helpless and I am gonna try other ways.
I don't know whether this would help, but this is the most I can get from profiling.
I think you need to compile rnote with force-frame-pointers=yes regardless of the the os to make it show on mac.
Going to try if I can get something out on mac this way.
And yes gtk being the gui toolkit, everything in rnote is called in a callback fashion from the gtk event loop.