After calling ``` ui_progress_bar_start("foo"); ... ui_progress_bar_stop(); ```
which should theoretically completely stop the progress bar, I get elevated CPU usage of the whole Geany process ~1% CPU on idle (and around 4% on macOS) compared to 0% after Geany launch before the status bar progress bar is used (e.g. by compiling). GTK seems to keep the widget connected to "tick callback" which causes the higher CPU (in fact, there's no gtk_progress_bar_stop() so it can't do it).
The workaround to fix this problem is to call ``` gtk_progress_bar_set_fraction() ``` which switches the progress bar to the mode where it shows the user-provided progress and this removes the "tick callback".
Am I crazy or can others reproduce this too? It was quite a bug hunt - first I suspected the LSP plugin (clangd indexes files on start which creates the progress bar which made it confusing), then jsonrpc-glib, then the blinking caret or Scintilla notifications, then Geany, and finally I got to GTK (3.24.38 to be precise).
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3902
-- Commit Summary --
* Fix elevated CPU usage after ui_progress_bar_start/stop() is used
-- File Changes --
M src/printing.c (2) M src/ui_utils.c (4)
-- Patch Links --
https://github.com/geany/geany/pull/3902.patch https://github.com/geany/geany/pull/3902.diff
Can't reproduce with: ``` 10:43:51: Geany INFO : Geany 2.1 (git >= 8ca4170b1), en_AU.UTF-8 10:43:51: Geany INFO : GTK 3.24.20, GLib 2.64.6 10:43:51: Geany INFO : OS: Linux Mint 20 (ulyana) ```
nor with GTK 3.24.38 and Glib 2.74.6 LMDE 6
PS I wouldn't say you are crazy, but your system might be ;-)
Well, if it happened just on one, it could be. But this happens both with the macOS binary and on Linux VM (on the same macOS but it's a different GTK backend). Basically the CPU oscillates somewhere between 0.3%-1.0% in `top` after first using the progress bar:
<img width="734" alt="Screenshot 2024-06-11 at 10 51 02" src="https://github.com/geany/geany/assets/713965/3522d620-fcb3-4101-87e1-021c31f87543">
Maybe its something about how graphics on native and the VM maps to the Macos graphics, both have to end up calling the same library that maps them into the Macos display, otherwise the machine display could get all messed up if "foreign" graphics were just allowed total control of the hardware.
I won't be able to check on a real linux/windows machine until the end of the week, I'll see then.
@b4n approved this pull request.
At first I thought you were silly indeed, because I couldn't reproduce the issue with a very simple build, and because I know the GTK API doesn't pulsate by itself, so it didn't make sense to me (and your OP wasn't clear enough for me to understand what's actually going one).
But then I tried with something a little heavier, meaning the progress bar had actually something more to do than merely maybe flashing, and I then could see it. Then going over the progressbar sources, I understood what you meant by "tick", and why it actually made sense. For the interested: although pulse steps have to be asked for explicitly (the progress bar doesn't simply start moving by itself), it still animates between pulse steps with a frame clock callback. However, it seems it's not shut off when the progressbar gets hidden. Setting a fraction value indeed leaves the so-called internal "activity mode" and disables the frame clock callback.
Merged #3902 into master.
then the blinking caret
When Geany is focused, I indeed gets it oscillating between 0% and 0.3%, which I'd blame on the blinking caret. When it's not focused and the caret isn't visible, it stays at 0%.
PS: we should really use better metrics than top's CPU percentage :grin:
@elextr BTW, do you use Wayland? I have no idea of the details of the frame clock thingy, by possibly the surface/windows getting shown/hidden could influence, given I would expect Wayland to *have* a frame clock, while X11 likely hasn't. Anyway, that could potentially be a factor. Or maybe Wayland is simply cheaper to draw on and our metric so poor it doesn't show up :)
@b4n Thanks for testing! I'll only be able to test on the real hardware tomorrow (edit: later today :-). But at least on the Xorg VM I use, when I added some printfs into `tick_cb()` of the GTK progressbar and recompiled GTK, it fired like crazy even after `ui_progress_bar_stop()`.
I think I'll report this to GTK because this is very unexpected - either there should be some `stop()` method in the API that does the same as `gtk_progress_bar_set_fraction(progressbar, 0.0)` or it should be documented that `gtk_progress_bar_set_fraction(progressbar, 0.0)` should be called to stop this.
…and I'd think it should definitely stop on unmap, there's no point in keeping tabs on the animation at that point I don't think.
@elextr BTW, do you use Wayland?
No.
…and I'd think it should definitely stop on unmap, there's no point in keeping tabs on the animation at that point I don't think.
That would fix it in our case but GTK shouldn't do this even when the progress bar is kept displayed all the time.
@elextr BTW, do you use Wayland?
No.
I think the CPU usage could be affected by the used theme - whether it has to draw rounded corners or not, some gradients, etc. When I tried to profile it, I could see some cairo operations (and lots of `poll()`s) in the profile.
Still I would suspect that `tick_cb()` from gtkprogressbar gets called all the time in your case too.
Maybe olde GTKs worked right and its a bug introduced by these young programmers, think they know everything gripe gripe [end grumpy olde guy rant] :grinning:
Maybe olde GTKs worked right and its a bug introduced by these young programmers, think they know everything gripe gripe [end grumpy olde guy rant] 😀
Oh yeah, it will be them. Those terrible young people aren't what they used to be in our times... :-)
By the way, I can reproduce this problem also on Wayland on Raspberry Pi - around 0.7% CPU.
I think I'll report this to GTK because this is very unexpected
Done in https://gitlab.gnome.org/GNOME/gtk/-/issues/6793
github-comments@lists.geany.org