yshui / picom

A lightweight compositor for X11 with animation support
https://picom.app/
Other
4.16k stars 589 forks source link

Disabling v-sync boosts performance with dual_kawase blur #624

Open paulhersch opened 3 years ago

paulhersch commented 3 years ago

Platform

Arch Linux amd64

GPU, drivers, and screen setup

Intel iGPU of i5-10600k xf86-video-intel and mesa up to date (its Arch), also installed libva and vulkan drivers 2 2k Monitors, one 75Hz (DP1) the other one 60Hz (HDMI1)

Environment

plain i3-gaps

picom version

vgit-7ba87

Configuration:

#################################
#             Shadows           #
#################################

shadow = true
shadow-radius = 8;

shadow-opacity = .75

shadow-offset-x = -7;
shadow-offset-y = -3;
shadow-exclude = [
  "name = 'Notification'",
  "class_g = 'Conky'",
  "class_g ?= 'Notify-osd'",
  "class_g = 'Cairo-clock'",
  "_GTK_FRAME_EXTENTS@:c"
];

#################################
#           Fading              #
#################################

# Fade windows in/out when opening/closing and when opacity changes,
#  unless no-fading-openclose is used.
# fading = false
fading = true;

# Opacity change between steps while fading in. (0.01 - 1.0, defaults to 0.028)
# fade-in-step = 0.028
fade-in-step = 0.03;

# Opacity change between steps while fading out. (0.01 - 1.0, defaults to 0.03)
# fade-out-step = 0.03
fade-out-step = 0.03;

# The time between steps in fade step, in milliseconds. (> 0, defaults to 10)
 fade-delta = 1.5

# Specify a list of conditions of windows that should not be faded.
# fade-exclude = []

# Do not fade on window open/close.
# no-fading-openclose = false

# Do not fade destroyed ARGB windows with WM frame. Workaround of bugs in Openbox, Fluxbox, etc.
# no-fading-destroyed-argb = false

#################################
#   Transparency / Opacity      #
#################################

# Opacity of inactive windows. (0.1 - 1.0, defaults to 1.0)
inactive-opacity = 1
#inactive-opacity = 0.8;

# Opacity of window titlebars and borders. (0.1 - 1.0, disabled by default)
 frame-opacity = 1.0
#frame-opacity = 0.7;

# Let inactive opacity set by -i override the '_NET_WM_OPACITY' values of windows.
# inactive-opacity-override = true
inactive-opacity-override = false;

# Default opacity for active windows. (0.0 - 1.0, defaults to 1.0)
# active-opacity = 0.95

# Dim inactive windows. (0.0 - 1.0, defaults to 0.0)
# inactive-dim = 0.0

# Specify a list of conditions of windows that should always be considered focused.
# focus-exclude = []
#focus-exclude = [ "class_g = 'Cairo-clock'" ];

# Use fixed inactive dim value, instead of adjusting according to window opacity.
# inactive-dim-fixed = 1.0

# Specify a list of opacity rules, in the format `PERCENT:PATTERN`,
# like `50:name *= "Firefox"`. picom-trans is recommended over this.
# Note we don't make any guarantee about possible conflicts with other
# programs that set '_NET_WM_WINDOW_OPACITY' on frame or client windows.
# example:
#   opacity-rule = [ "80:class_g = 'URxvt'" ];
#   opacity-rule = [ "80:name *= 'discord'" ];
   opacity-rule = [ "80:class_g *= 'rofi'"];
#
# opacity-rule = []

#################################
#     Background-Blurring       #
#################################

# Parameters for background blurring, see the *BLUR* section for more information.
blur-method="dual_kawase";
blur-strength = 4
blur-background = true
blur-background-frame = false
blur-background-fixed = true

#################################
#       General Settings        #
#################################

# Daemonize process. Fork to background after initialization. Causes issues with certain (badly-written) drivers.
 daemon = true

# Specify the backend to use: `xrender`, `glx`, or `xr_glx_hybrid`.
# `xrender` is the default one.
#
backend = "glx";

glx-no-stencil = true

#vsync = true;

# Enable remote control via D-Bus. See the *D-BUS API* section below for more details.
dbus = true

# Try to detect WM windows (a non-override-redirect window with no
# child that has 'WM_STATE') and mark them as active.
mark-wmwin-focused = true;

# Mark override-redirect windows that doesn't have a child window with 'WM_STATE' focused.
# mark-ovredir-focused = false
mark-ovredir-focused = true;

detect-client-opacity = true;

# Specify refresh rate of the screen. If not specified or 0, picom will
# try detecting this with X RandR extension.
#
refresh-rate = 0

# This cause the whole screen to be redrawn everytime, instead of the part of the screen
# has actually changed. Potentially degrades the performance, but might fix some artifacts.
# The opposing option is use-damage
#
# no-use-damage = false
  use-damage = true

transparent-clipping = false

log-level = "warn";

wintypes:
{
  tooltip = { fade = true; shadow = true; opacity = 0.75; focus = true; full-shadow = false; };
  dock = { shadow = false; }
  dnd = { shadow = false; }
};

Steps of reproduction

  1. enable vsync, open one terminal with transparent background (accurs when the blur is in use)
  2. do some regular user stuff like browsing the web

Expected behavior

vsync shouldn't affect the performance of basic desktop applications like Firefox

Current Behavior

Using Firefox or Chromium with vsync and dual_kawase blur creates immense choppiness, disabling vsync makes the windows smooth again

Other details

tryone144 commented 3 years ago

Is the choppiness gone when disabling dual_kawase blur but enabling vsync? I am kinda curios because your monitors have different refresh-rates.

paulhersch commented 3 years ago

Yeah it was gone when I disabled dual_kawase, i guess the iGPU isn't really strong enough for vsyncing different rates and blurring at the same time, as I don't have the same issues when using my Nvidia GPU (with 75Hz and 144Hz on X and vsync=0). I also had noticeably worse performance when using the ibhagwan fork with rounded corners and blur at the same time, so I really think its the iGPUs fault.

For testing purposes I could still boot into my Void Linux install, where i have the ibhagwan fork installed rn if You change some code and need stuff to be tested.

yshui commented 3 years ago

Interesting, I wonder what's the effective render rate with vsync enabled.

subnut commented 3 years ago

@yshui Is there any way to show the effective render rate?