Higher CPU usage / lower battery life with this picom fork

[tim-kilian]

Here is a direct comparison screenshot I've taken to compare this picom branch with the master branch. In my opinion it should not make a difference when you're not moving your windows. Because animations are not happening in a idle state. Only when switching windows / adding windows I would expect a higher resources usage. In my opinion this makes it impossible to use on a mobile laptop environment.

sample htop and powertop with dccsillag picom in idle state
comparison htop and powertop with yshui picom in idle state

[dccsillag]

While there is some cost to animations, even when nothing is happening, it should be miniscule (e.g., checking if each window should be animated) -- which doesn't appear to be the case, at all.

I'll take a look later today.

[dccsillag]

Ah, just to check, the first screenshot is with this fork, not @pijulius', right?

(It shouldn't make a difference, performance-wise, but so that I know what I should be debugging.)

[tim-kilian]

yes. I can make a screenshot with pijulius too.

[dccsillag]

No need.

[godalming123]

I am also getting high cpu usage

[godalming123]

Is it possible that when you close a window picom is still rendering the window but just with no opacity so it starts to clog up video memory?
Just because sometimes when I close a window - I have a scale window close animation - it will stay on the screen as only a few pixels that can barely be seen and never disipears indicating its still being rendered

[dccsillag]

Hmmmmm..... it really shouldn't. But I'll take a look at it; if you are right, than not only are we rendering unnecessary stuff but we also have a memory leak.

Which WM do you use, BTW?

[godalming123]

I use bspwm and can also test on awesome

[tim-kilian]

I can confirm for qtile and xmonad

[podiki]

Can confirm here too (xmonad), seeing one thread at nearly 100% even when doing nothing.

[dccsillag]

I guess this is worth a try -- does this patch help anything for you guys?

diff --git a/src/picom.c b/src/picom.c
index 1e41768..9b11e66 100644
--- a/src/picom.c
+++ b/src/picom.c
@@ -1662,7 +1662,7 @@ static void draw_callback_impl(EV_P_ session_t *ps, int revents attr_unused) {
        if (!animation_running && ev_is_active(&ps->animation_timer)) {
                ev_timer_stop(EV_A_ & ps->animation_timer);
        } else if (animation_running && !ev_is_active(&ps->animation_timer)) {
-               ev_timer_set(&ps->animation_timer, 0, 0);
+               ev_timer_set(&ps->animation_timer, 1000, 0); // yes, an absurdly high number
                ev_timer_start(EV_A_ & ps->animation_timer);
        } 

In any case, it would help immensely if one of you managed to run a profiler (I think picom even has some profiling mechanism baked in) -- I really can't reproduce any of this here (I think it's because rendering is the bottleneck in all the machines I have access to -- they don't have powerful graphics hardware). It's rather tough to do this through guesswork.

[dccsillag]

@godalming123

Is it possible that when you close a window picom is still rendering the window but just with no opacity so it starts to clog up video memory?
Just because sometimes when I close a window - I have a scale window close animation - it will stay on the screen as only a few pixels that can barely be seen and never disipears indicating its still being rendered

You mention window close animations -- so this is on #22, right? Does this persistance thing also happen in this repo (without the code from the PR)?

Also, @tim-kilian and @podiki: when you confirmed to also experience the issue did you mean just the performance issues or the persistant windows as well?

[godalming123]

Yes that is on pijulios's fork. I can try on you fork

[godalming123]

Should I use the normal branch or the implement window animations branch

[godalming123]

Based on quick testing I can verify that I do not have the issues on your fork implement window animations branch

[dccsillag]

Oh, phew! Thank you for confirming.

I do remember @pijulius mentioning that there was some memory leak on his work after the workspace animations, so that might be it.

(Yes, the implement-window-animations branch. The next branch is just the same as upstream picom.)

[godalming123]

In fact all of the issues I was experiencing on pijuilio's fork are gone. No buggy workspace transitions where the window on the last workspace is still visible, I don't have glitches with the scale transition and I am no longer experiencing a memory leak or slow downs and my rounded corners work as well as opacity transitions! And since I use the glx backend I dont have any of the bugs pijulios's fork fixes however I do have a new bug for rounded corners see #28

[dccsillag]

In fact all of the issues I was experiencing on pijuilio's fork are gone. No buggy workspace transitions where the window on the last workspace is still visible, I don't have glitches with the scale transition and I am no longer experiencing a memory leak or slow downs and my rounded corners work as well as opacity transitions!

Great! But this does not include the performance issue reported in this thread, right?

Also, BTW, I merged the rounded corners stuff just yesterday.

And since I use the glx backend I dont have any of the bugs pijulios's fork fixes however I do have a new bug for rounded corners see #28

I've commented on the other issue.

[godalming123]

So far I haven't noticed any degradation in performance

[dccsillag]

Compared to what?

[tim-kilian]

The performance issues got better with ev_timer_set(&ps->animation_timer, 1000, 0); // yes, an absurdly high number, but still not acceptable for me. When you tell me how to run a profiler I can try to profile it.

Also while testing I noticed a few bugs with the animations:

1. A drawing delay for rounded corners
2. Electron apps seems to leave artifacts

Should I create Issues for this?

[dccsillag]

The performance issues got better with ev_timer_set(&ps->animation_timer, 1000, 0); // yes, an absurdly high number, but still not acceptable for me. When you tell me how to run a profiler I can try to profile it.

ok

Also while testing I noticed a few bugs with the animations:

1, A drawing delay for rounded corners
2. Electron apps seems to leave artifacts

Should I create Issues for this?

Yes, please!

I'll be a bit busy for the rest of today, but I'll likely be able to take a look at them in the next few days.

[podiki]

My quick test shows that the patch (which I had to redo since it wouldn't apply cleanly) does help the idle CPU usage: no longer is one core on my machine staying in the 90%+ range at max CPU frequency. But then the animations become unusable, just a few frames and sometimes freezing slightly.

Without that patch I see nice, smooth animations, but with one core staying at high usage even when nothing is animated.

(And yes, I was only referring to the CPU usage, as in the issue title, not any other problems.)

Edit: And to be clear, I'm comparing upstream picom (current git commit) to this fork (current git commit)

[godalming123]

Compared to what?

Compared to pijulios's fork

[Mojavve]

I am also getting higher CPU usage compared to regular picom and compared to jonaburg's old fork. I am on a ryzen 3600x and with yshui's picom my CPU idles at like 1-2% with general things like firefox open and with your fork (dccsillag's implement-window-animations branch) my CPU idles at 15%, with some cores constantly at 70-90%. The animations are incredible though, perfectly smooth.

---

CPU: AMD Ryzen 5 3600x
GPU: Nvidia GTX 970
OS: EndeavourOS (essentially Arch)
WM: XMonad
Kernel: 5.16.11-arch1-1
dccsillag's Picom version: cloned on 2022-03-02 at around midnight CST
yshui's picom version tested: Picom 9.1-2
Extra details: using glx backend, --experimental-backend used as well. Tried with vsync on and off.

[pdf]

I've been trying to track down what appears to be a rather significant memory leak. What's interesting is that the memory usage was not attributed to a process - the kernel reported huge memory consumption (~15-20GB), but no process appears to own the memory. I only noticed the issue after switching to this fork, and having switched back to upstream, the leak appears to have gone away.

Is it possible that texture memory on the GPU could be leaked or something? I'm using Intel integrated graphics, so GPU memory is allocated from system memory, and that's the only explanation I could come up with to account for the lost memory. I have no idea how to debug this though.

[dccsillag]

Whoaa, that's troubling. Thanks for looking into it.

Your hypothesis about these being leaked textures makes some sense; if I remember properly, picom (without my code) stores a single texture on the managed_win object, and, with my code, it stores 1-2 textures (the original one and another one for the pixmap blending). Thing is, these textures (which I believe are typed as backend_image in the code or something similar) are reference counted, and since this is C we have to manually manage the reference counting. So yeah, I think it's possible that there is some place where we never decrement the reference count, leading to leaking textures -- this is worth looking into.

Unfortunately, I won't be able to personally look into this in depth right now (maybe in a couple of weeks?), but I'll try to be available here to exchange some ideas.

P.S.: what is your kernel version? Is it LTS?
P.S.(2): also, valgrind may be of use in debugging this, just make sure you're using a debug build.

[pdf]

P.S.: what is your kernel version? Is it LTS?

It was 5.18.0 when I tested, can potentially try some other version if you have an idea that this might be related.

P.S.(2): also, valgrind may be of use in debugging this, just make sure you're using a debug build.

I'm not sure if valgrind will catch these allocs, and I'm a pretty time-poor myself atm, I'll see if I can find some though.