Poor animation performance with shadows on Intel graphics

[podiki]

As described in #2, I'm finding animations to not really show (sort of skipping the frames) while on an Intel integrated graphics card, but not on an Nvidia GPU. This is on a 4k screen, experimental-backends, glx, with features like the dual-kawase blur enabled. Happy to provide any other information and test updates in the future.

[dccsillag]

Do you have animation clamping enabled?

[podiki]

....I don't know. As far as I know the only animation setting I have is to turn it on, so whatever is the default as of the last commit I pulled a few days ago I think (would have to confirm the version).

[dccsillag]

I've just checked, and it appears that the default is animation-clamping = true. Could you try disabling it (i.e., animation-clamping = false)? How much does that (disabling) help with performance?

[podiki]

It leads to seeing sort of a blink, but perhaps more sluggish. Not much difference really.

[dccsillag]

Try disabling shadows as well?

[dccsillag]

Another thing I'd love to know is how many windows picom is trying to animate per frame. But I need to think a bit on how to measure this without changing the code, or make a patch (if it's not too bothersome for you).

[podiki]

Yes, with shadows disabled you see the animation, and slightly better with clamping off. Sometimes there is no animation, just immediate transition (must not be able to render the frames in time?) which happens less with clamping off in my quick test. So shadows are still the culprit.

[dccsillag]

Update:

The main bottleneck appears to be the bind_pixmap call in default_backend_render_shadow. Which is weird, and I don't think should be the case.

Possibly related, I've noticed that when shadows are on I eventually get errors like

[ 26/08/2021 17:34:03.514 x_create_pixmap ERROR ] Failed to create pixmap (X error 11 ALLOC request 53 minor 0 serial 11918)
[ 26/08/2021 17:34:03.514 x_create_pixmap ERROR ] Failed to create pixmap (X error 11 ALLOC request 53 minor 0 serial 11920)
[ 26/08/2021 17:34:03.514 build_shadow ERROR ] Failed to create shadow pixmaps
[ 26/08/2021 17:34:03.518 win_bind_shadow ERROR ] Failed to bind shadow image, shadow will be disabled for 0x02800006

sometimes followed by a segfault, even.

Checked on some older commits as well -- these errors also happened there.

EDIT: those were a totally different issue (#15), which is now solved. The performance problem in this issue persists.

[dccsillag]

Related issue: https://github.com/dccsillag/picom/issues/15

[dccsillag]

I did some work that should help this at least a bit. I tried it out on a pretty weak machine I have here, and it looks like it helped a tad; could you try it out?

(NOTE: it looks like sometimes, in the current code, windows diverge [I'll open an issue for that in a bit]. But if at least animations are visible now, that's really good progress.)

[podiki]

I think it has helped a bit too, by that I mean some more animation frames are visible. Now it does look more clearly (usually, some are still skipped entirely) like there are animations but unable to render enough frames or quick enough to make it smooth. To contrast with before, when it wasn't clear on my end what was happening.

By the way, I appreciate the work here, but I'm certainly fine with accepting that the ol' integrated Intel graphics won't do 4k resolution blurred (dual kawase) windows with shadows and animations all together. Better performance is always nice of course, but if this is an outlier case I would think there are more fun things to work on here.

[dccsillag]

I think it has helped a bit too, by that I mean some more animation frames are visible. Now it does look more clearly (usually, some are still skipped entirely) like there are animations but unable to render enough frames or quick enough to make it smooth. To contrast with before, when it wasn't clear on my end what was happening.

Great!

By the way, I appreciate the work here, but I'm certainly fine with accepting that the ol' integrated Intel graphics won't do 4k resolution blurred (dual kawase) windows with shadows and animations all together. Better performance is always nice of course, but if this is an outlier case I would think there are more fun things to work on here.

I might just do that, depending on a test -- could you check what your performance is like for when you resize windows with the mouse (i.e., via the window manager)? Is it comparable to the performance for the animations?

I ask because the bottleneck is clearly the way Picom does shadows -- whenever the geometry changes, it frees the current shadow pixmap and allocates a new one with the new size. Tecnically, we could do the animation code differently in order to avoid this, however, that would greatly increase the diff (and create space for much more bugs, even for when animations are disabled) and might cause performance problems for the xrender backend. Then, of course, there's the possibility of speeding up the current shadow code itself, but I don't really have any idea how to do that (but maybe the upstream folks do).

So, I'm going down the following path: if resizing with the mouse also has these performance issues, then we are moving on and just adding a warning that, since the current shadow code is a bit slow, it may cause quite a bit of latency on weaker hardware. However, if resizing with the mouse is even relatively smooth, then it would seem that we're doing something quite wrong, and I'll look more into fixing it. It might not be the most fun thing to work on, but it should be done.

(BTW: about weaker hardware -- the "strongest" hardware I have is also an Intel integrated graphics chip, so it's not a "you must have a GPU for this" situation.)

[podiki]

Whoops, thought I had responded to this a long time ago.

Hmm...a bit of a hard thing to judge for me. With shadows resizing a window is not as smooth, slightly better with shadows off I think. Not nearly as smooth as with picom disabled. It might also be a little hard to judge as with animations there is more to see (more motion and frames) so it is easier to notice.

So I'm not sure what this means. Resizing with picom and shadows off is still noticeably different from with it on (shadows or no), so it could be a general performance issue (with picom, high res, my hardware and config, ...).