picom icon indicating copy to clipboard operation
picom copied to clipboard

Stuttering when using xrandr with scaled output

Open mrossinek opened this issue 5 years ago • 9 comments

Platform

Arch Linux:

% uname -r
5.6.2-arch1-2

GPU, drivers, and screen setup

Dual graphics. Configured with Prime render offload. Using the modesetting driver for the Intel graphics.

Intel

  GL_VERSION:  4.6 (Compatibility Profile) Mesa 20.0.4
  GL_VENDOR:   Intel
  GL_RENDERER: Mesa Intel(R) UHD Graphics 620 (KBL GT2) 

Nvidia

  GL_VERSION:  4.6.0 NVIDIA 440.64
  GL_VENDOR:   NVIDIA Corporation
  GL_RENDERER: GeForce MX150/PCIe/SSE2

xrandr

% xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x47 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 5 associated providers: 0 name:modesetting
Provider 1: id: 0x269 cap: 0x0 crtcs: 0 outputs: 0 associated providers: 0 name:NVIDIA-G0
% xrandr
Screen 0: minimum 320 x 200, current 4480 x 1440, maximum 16384 x 16384
eDP-1 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 309mm x 174mm
   2560x1440     60.01*+  59.99    59.99    59.96    59.95
HDMI-2 connected 1920x1080+2560+0 (normal left inverted right x axis y axis) 527mm x 297mm
   1920x1080     60.00*+  50.00    59.94

Environment

I am using XMonad version 0.15 Nothing special happening here.

picom version

This happens with both, the picom and picom-git packages. For the latter:

% picom --diagnostics

Version: vgit-b37db

Extensions:

  • Shape: Yes
  • XRandR: Yes
  • Present: Present

Misc:

  • Use Overlay: No (Another compositor is already running)
  • Config file used: /home/max/.config/picom.conf

Drivers (inaccurate):

modesetting

Configuration:

Note: I am using picom to solve a tearing problem I observe when using the modesetting driver. The xf86-video-intel driver is not an option because it does not work with the Prime render offload method I use for dual graphics. picom resolves the tearing issue flawlessly when using a single monitor or a second one which is unscaled. Since I use picom solely for this, all fancy visuals are disabled.

# Backend
backend = "glx";

# GLX backend
glx-no-stencil = true;

# Shadows
shadow = false;

# Opacity
inactive-opacity = 1;
active-opacity = 1;
frame-opacity = 1;
inactive-opacity-override = true;
blur-background-fixed = false;

# Fading
fading = false;

# Other
mark-wmwin-focused = false;
mark-ovredir-focused = false;
use-ewmh-active-win = true;
detect-rounded-corners = false;
detect-client-opacity = true;
detect-transient = false;
detect-client-leader = false;
refresh-rate = 0;
vsync = true;
dbe = false;
unredir-if-possible = false;

# XSync
# See: https://github.com/yshui/picom/commit/b18d46bcbdc35a3b5620d817dd46fbc76485c20d
xrender-sync-fence = true;

Steps of reproduction

  1. connect a second monitor and scale its output with xrandr. e.g.: xrandr --output HDMI-2 --auto --scale 1.33x1.33 --right-of eDP-1 --auto
  2. scroll in a window (e.g. browser) on the unscaled monitor or play a video with mpv and move the mouse over it

Expected behavior

The same behavior as with an unscaled output:

  • no stuttering
  • no flickering of the mouse Just a nice and smooth experience.

Current Behavior

The following observations can be made everywhere:

  • the system appears unresponsive, but
    • mpv does not drop frames (observed with Shift+i)
    • screen recordings do not show the behavior outlined below
    • thus, I conclude it is merely a presentation issue and not the system actually lagging

Only observable on the unscaled monitor (here eDP-1):

  • the mouse flickers when positioned in a part of the screen which is frequently updated (e.g. an mpv window or when scrolling in a browser)
  • the glxheads demo shows tearing (but not in a recording)

When picom is not running I do not observe these problems but the aforementioned tearing issues I am trying to resolve through the use of picom.

Stack trace

picomp does not crash.

Other details

As mentioned before, the problem cannot be recorded through screen capturing. I tried... I also tried playing around with the configuration options but did not find a solution.

mrossinek avatar Apr 09 '20 22:04 mrossinek

i guess the exact look of stuttering will be helpful in understanding the origin of the issue and debugging it, so would be good if you can capture it using your mobile phone, for example.

also, does this happen if you disable offloading? try to use only intel gpu and then only nvidia gpu.

absolutelynothelix avatar Apr 10 '20 07:04 absolutelynothelix

Yes of course! I wanted to check first whether this has been heard of before. I will make the recording later today.

mrossinek avatar Apr 10 '20 08:04 mrossinek

Okay I made a video capturing all relevant cases. I had to split it into three uploads though:

  1. Only Laptop monitor is used: everything behaves normally: https://imgur.com/jNtR2jN
  2. External screen is used with normal resolution: everything behaves normally: https://imgur.com/s4890Q0
  3. External screen is scaled: the internal screen shows the aforementioned problems: https://imgur.com/XRuFUnQ

Some notes on part 3:

  • the mouse is flickering while in regions where the screen is refreshed frequently
  • the mouse even vanishes when moved in the top half of the glxheads demo
  • the glxheads demo shows visual artifacts near the top

Note: the glitch when switching to the external monitor was a fluke. I have not seen that happen before.

mrossinek avatar Apr 10 '20 10:04 mrossinek

@mrossinek mouse cursor is not rendered by (not a responsibility of) the compositor, making me thinking this is a driver issue.

yshui avatar Apr 12 '20 07:04 yshui

Okay interesting. Then I wonder though why this only happens while picom is running. And the tearing visible in the glxheads demo and the stuttering of the system when e.g. playing a video with mpv are still not explained by that, though.

I can't really image this, but could it be a problem due to the number of pixels having to be rendered?

mrossinek avatar Apr 12 '20 09:04 mrossinek

@mrossinek vsync doesn't work under scaling isn't a surprise to me. Previously it was reported to not work when screen is rotated (#328). There was nothing picom can do there either, and a bug was reported to Xorg. I recommend you do the same thing for these two issues.

I will look into the stuttering.

yshui avatar Apr 12 '20 11:04 yshui

Awesome thanks a lot! I did not notice #328 before. I will go ahead and report this bug to xserver just like discussed in #328. I will link here and to both of the rotating issues too, just for completeness.

Thanks for the fast reply :blush:

mrossinek avatar Apr 12 '20 12:04 mrossinek

Link to xserver issue: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1013

mrossinek avatar Apr 12 '20 13:04 mrossinek

Same issue with picom + scaled output on a secondary screen. Reading the xserver issue linked in https://github.com/yshui/picom/issues/328, it mentions tearfree.

Enabling tearfree on the non scaled display fixes the issue with my setup:

$ xrandr --output eDP --set TearFree on --auto --output DisplayPort-1 --auto --scale 2x2 --right-of eDP

$ xrandr 
Screen 0: minimum 320 x 200, current 6720 x 2400, maximum 16384 x 16384
eDP connected primary 2880x1920+0+0 (normal left inverted right x axis y axis) 285mm x 190mm
   2880x1920    120.00*+  60.00 +

DisplayPort-1 connected 3840x2400+2880+0 (normal left inverted right x axis y axis) 477mm x 268mm
   1920x1200     59.88*+  59.88  

BarbUk avatar Jul 07 '25 21:07 BarbUk