2 frames 2 pacing

[yshui]

Another batch of frame pacing improvements. Hopefully it's acceptable for general use now.

Fixes #1072

[codecov]

Codecov Report

Attention: 402 lines in your changes are missing coverage. Please review.

Comparison is base (e76cf43) 37.41% compared to head (d8f3037) 36.68%.
Report is 4 commits behind head on next.

Additional details and impacted files

@@            Coverage Diff             @@
##             next    #1156      +/-   ##
==========================================
- Coverage   37.41%   36.68%   -0.73%     
==========================================
  Files          49       50       +1     
  Lines       11197    11489     +292     
==========================================
+ Hits         4189     4215      +26     
- Misses       7008     7274     +266     

Files	Coverage Δ
src/backend/driver.h	60.00% <ø> (ø)
src/common.h	75.00% <ø> (ø)
src/config.h	23.52% <ø> (ø)
src/event.c	69.72% <ø> (ø)
src/x.h	87.50% <ø> (ø)
src/statistics.c	32.43% <0.00%> (+4.52%)	⬆️
src/backend/backend.c	62.12% <66.66%> (+1.20%)	⬆️
src/utils.h	29.41% <50.00%> (ø)
src/backend/driver.c	31.11% <0.00%> (-3.04%)	⬇️
src/x.c	44.54% <0.00%> (-1.62%)	⬇️
... and 3 more

... and 1 file with indirect coverage changes

[FT-Labs]

@yshui

Hi,

I'm not much aware of the frame pacing topic but when enabled with animations (glx, xrender) everything seems to be messed up. After opening several windows any window movement/resize becomes too laggy and crashes everything eventually (all windows disappear or start making awkward movements).

Can you guide me a little bit about frame pacing? I'm not sure if it should be included with animations though. Also my fork is not like other forks, it is 100% original picom (this one) with animations included in it. I also maintain all of your commits, so that it is not behind of the original.

	if ((ps->o.legacy_backends || ps->o.animations || ps->o.benchmark || !ps->backend_data->ops->last_render_time) &&
	    ps->frame_pacing) {
		// Disable frame pacing if we are using a legacy backend or if we are in
		// benchmark mode, or if the backend doesn't report render time

Also if you have a little bit of free time I have one more question, it is not related to this issue.
Since animations (resize/window movements) trigger hundreds of events (clear window flags/set window flags/add damage etc) in a second I think this increases CPU usage and decreases performance a bit; since if animation is not used it will trigger only once per one event. Or for example, picom spams logs because it tries to clear flags of a destroyed window (it fades out and triggers a custom animation) but window is unmapped/destroyed from X. Previously I just blocked sending logs if the window animation is still in process but it is not an ideal solution, since it only blocks sending log messages, I wonder if there is any way to do it without those functions being called?

[yshui]

@FT-Labs can you try merging this branch with your animation branch?

[yshui]

@FT-Labs btw, what's the current status on animation? judging from the PRs there are multiple efforts on animation, and i don't know how they are related to each other.

[FT-Labs]

@yshui

I've merged the code with this branch and it fixed all performance issues. There is no performance issue with frame pacing enabled now.

https://github.com/FT-Labs/picom/tree/pacing-fixes

It is close to done actually, I do not have that much idea about other forks. As a start, I have used @dccsillag's fork 1 1-5 years ago, but a lot has changed since it did not get updated. I just try to keep in line with original picom without breaking the animations.

To sum up, here is what works now:
Shadows without glitches
Smooth animations without using too much cpu/memory
Fade out destroyed/unmapped windows
~10 different animations
Open/close window animations
Workspace switch animations
Works with custom shaders
No flickering on any transparent window (focused/not focused) when resizing/moving

Remaining problems:
Make workspace switch animation behave correctly for any WM/DE

• This is troublesome because workspace/tag/desktops are dependent on developers, and there is no strict rule. However, the preferred way is set all of NET_WM_DESKTOP of all windows then change NET_CURRENT_DESKTOP atom of root window. The issue is while awesomewm or xmonad follows this rule but other wm like dwm have different implementations
  Sometimes workspace switch animation can go towards center of root viewport instead of going to the center of current monitor. This issue only occurs on multiple monitor setups. Like minimize animation shrinks all of the visible windows to the center of monitor.
  Some people reported glitches with some layouts in bspwm, most of them are solved with disabling pacing before this branch.

Aside from these it is done and works good. Of course, there could be more improvements but I think they can be done later since they would classify as features

[yshui]

@FT-Labs cool. after 11 is out of the door, the focus for 12 would be getting animation over the finishing line

[Stebalien]

I'm no longer noticing any power draw differences introduced by frame pacing when running this branch, but I've also switched from Intel to AMD so I don't get quite the same level of power state information 🤷.

[FT-Labs]

@yshui sorry if it is a stupid question, what is 11 and 12 :D

[absolutelynothelix]

@FT-Labs, picom v11 and v12 respectively.

[FT-Labs]

Ok, got it

[morgoth6]

It seems if smart_frame_pacing is enabled, picom log-spam huge amount of warnings:

PresentCompleteNotify msc is going backwards, last_msc: 767522245 , current msc: 0

As soon as for display turns off (DPMS) In my case my picom.log grow to 2GB+ (and eats quite significant portion of my battera at the same time)

Maybe it would be good idea to utilize DPMSInfoNotify ? It should be working now (#134) and for older systems it would be no-op (?)

[yshui]

Wow, DPMSInfoNotify is merged?! Never thought I'd see this day 😆

[yshui]

Things seem to be going well, so I am merging this.