search

tildearrow / kwin-lowlatency

archived - X11 full-screen unredirection and lots'a settings for KWin
373 stars 10 forks source link

On high refresh rate monitors, Chrome still runs at 60fps until I do kwin_x11 --replace #34

Closed urbenlegend closed 2 years ago

urbenlegend commented 5 years ago

So kwin_lowlatency does a great job of detecting and setting my 144Hz monitor and correctly making the compositor repaint at 144Hz, unlike regular kwin. However, it still has the same bug where certain apps will still repaint at 60Hz. I've already submitted a similar bug for this issue on the official KDE bug tracker, but it's over a year old and the developer is completely unresponsive on it now. So I figured I'd post the bug here since this issue is very closely related to latency and stutter.

The biggest example of this bug is Google Chrome/Chromium (and I am assuming all apps that use Chromium embedded, like Discord). Here are steps to reproduce.

  1. Attach a single 144Hz monitor. (Although, I have a feeling this bug will occur on all monitors capable of > 60Hz)
  2. Go to Display settings and set the refresh rate to 144Hz.
  3. Reboot and log in.
  4. Launch Google Chrome and go to www.vsynctester.com. Note that the screen repaints at 60Hz.
  5. Relaunch kwin_lowlatency with kwin_x11 --replace
  6. Notice that www.vsynctester.com now reports 144Hz. Animations are also much smoother.

You can also verify this by using qdbus org.kde.KWin /KWin supportInformation before and after kwin_x11 --replace. In the Screen 0 section, this command will report refresh rate is at 60. After restarting kwin, the command correctly reports the actual refresh rate of 144Hz.

Workarounds

  1. If I set the SDDM login screen to run at 144Hz, then Google Chrome will run at 144Hz on first login. Usually SDDM defaults to 60Hz. I am guessing when Kwin is setting the monitor frequency on login, it isn't setting the right values in all the places it needs to?
  2. If you put kwin_x11 --replace inside an Autostart script, this also fixes the issue on login.

Neither of these workarounds are optimal though because if you change the refresh rate later on in Display settings, the affected apps will still run at the old refresh rate.

Sorry if this is too long winded of a report, I'd be happy to provide more info and help with debugging.

Thanks for all your great work!

tildearrow commented 5 years ago

This means... ...maybe the unused RefreshRate variables are still being used somewhere? I'll take a look at it in a few hours and try to determine the cause.

tildearrow commented 5 years ago

Possible bug reproduced: set display to 50Hz (sorry, I don't own a high-rate display), graph is stable. After switching to 60Hz, the graph varies wildly.

Indeed, changing refresh rates doesn't change screen refresh rate in support info.

urbenlegend commented 5 years ago

@tildearrow Also, if you simply run xrandr with no arguments, it will make Chrome adjust to the proper refresh rate. It's really quite weird.

ms178 commented 4 years ago

During testing a recent openSuse Tumbleweed build, I noticed a huge amount of frame drops on Youtube (H.264) while using Chromium /w VAAPI on a Vega 56 with KWin-low-latency and a 144 Hz monitor with KDE Plasma (OpenGL 3.1). The videos were in FullHD with 60 Hz and if I set my monitor to 120 Hz, the frame drops were gone. Is this related to this issue or a seperate issue?

danbulant commented 3 years ago

Getting the same problem - I somehow fixed it before, but after KDE update I'm getting 62 refresh rate on chromium (60 on firefox). Using the kwin_x11 --replace worked, didn't try running just xrandr.

Might be problem on xrandr part since chromium uses refresh rate from xrandr. It possibly has some form of cache that doesn't get updated until you run the command.

tildearrow commented 2 years ago

Can't reproduce anymore. Hopefully fixed in upstream.