search

tildearrow / kwin-lowlatency

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

Broken/slowed down Animations when VSync is turned off #42

Closed tam1m closed 2 years ago

tam1m commented 5 years ago

Video of the problem

Since the 5.16.5 update, kwin-lowlatency has issues with animations on my system. The video demonstrates whats happening. Animations are being played really slowly or even getting stuck, until something else on the screen is drawn. Like selecting something on the desktop or moving another window while the animation is being played, fixes the animation. Even recording the screen altered this behaviour quiet a bit. Animations were being played more smoothly, depending on the recordingframerate, although still still stuttery and not at the right speed.

This happens when the vsync mechanism is set to anything else, but "SGI video sync with horrible hack" ~or backend set to Xrender~. Also disabling my second monitor does not change this behaviour. Upstream kwin works as intended on my system.

Let me know, if you need any more information or testing.

edit: Using Xrender shows the same problem Problem.

My system: Arch Linux Nvidia 435.21 (GTX 970) Intel i7-8700k kwin 5.16.5 plasmashell 5.16.5

tildearrow commented 5 years ago

Thanks for the bug report.

Can you please return the output of xrandr? I need to know the monitors' refresh rates.

tam1m commented 5 years ago

Sure, thats my monitor configuration 

Screen 0: minimum 8 x 8, current 3600 x 1080, maximum 16384 x 16384
DVI-I-0 disconnected (normal left inverted right x axis y axis)
DVI-I-1 connected primary 1920x1080+1680+0 (normal left inverted right x axis y axis) 531mm x 298mm
1920x1080     60.00 + 144.00*  119.98    99.93  
1440x900     119.85
1280x1024    119.96    75.02    60.02
1024x768     119.99    75.03    60.00
800x600      119.97    75.00    60.32
640x480      120.01    75.00    59.94
HDMI-0 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 473mm x 296mm
1680x1050     59.95*+
1600x1000     60.00
1440x900      59.89
1280x1024     75.02
1280x960      60.00
1152x720      60.00
1024x768      75.03    60.00
800x600       75.00    60.32
640x480       75.00    59.94
tildearrow commented 5 years ago

144 Hz.......

Anyway, I have pushed some commits. Can you please test on the latest Git version and tell me if "Hope for the best" improves the situation?

tam1m commented 5 years ago

I just tried the latest git version, but nothing changed. I also tried both monitors on 60 Hz and only a single monitor on 60 Hz, but the problem persists regardless of the configuration.

tildearrow commented 5 years ago

This is indeed very strange as I haven't been able to reproduce this in my system (tried AMD, NVIDIA and even NVIDIA under multi-monitor, but could not reproduce).

Can you try a single monitor on 60Hz and then after setting the refresh rate, restarting the compositor?

tam1m commented 5 years ago

Ok so, I tested a few configurations including single monitor set to 60 Hz. That didn't change anything.

But then I created a completely new user, logged in and kwin_lowlatency works perfectly fine. No problems at all. It must be something in my user config, but I can't find it.

Things I tried:

Any idea what else it could be?

Edit:

I found the it. I had the "Allow Flipping" switch disabled in nvidia-settings. Turning it back on fixes everything, but in turn, performance is way worse. Moving windows etc. is really stuttery (feels more like 60Hz than 120+) and the latency increases noticeably.

tildearrow commented 5 years ago

You can enable the "Show FPS" effect to confirm that's the case, and if so, try tweaking the min/max latency reduction in the Compositing settings.

If the latency does increase, I'll have to look into that...

(by the way, have you disabled any of the "Force Composition Pipeline" options? Hope you did)

tam1m commented 5 years ago

Well I spoke too soon. When I enabled flipping while testing, it worked, but after a reboot the problem.

image image image image

tildearrow commented 5 years ago

This is a problem because so far I have been unable to reproduce this, and the worst is that if this is related to the 144Hz monitor then this will be much more complicated due to the fact I don't have a 144Hz monitor and can't afford one at the moment. I will try harder to reproduce this problem in around 1-2 hours when I come back to my machine, but in the meanwhile:

Can you print the output of qdbus org.kde.KWin /KWin supportInformation, and the list of active desktop effects and KWin scripts? (or better yet, your kwinrc (strip/remove any file paths or sensitive information first)?)

tam1m commented 5 years ago

Sorry I couldn't get back to you earlier.. timezones..

This is a problem because so far I have been unable to reproduce this, and the worst is that if this is related to the 144Hz monitor then this will be much more complicated due to the fact I don't have a 144Hz monitor and can't afford one at the moment.

I don't think it is related to 144Hz since it also happens with a single 60Hz monitor.

Can you print the output of qdbus org.kde.KWin /KWin supportInformation, and the list of active desktop effects and KWin scripts? (or better yet, your kwinrc (strip/remove any file paths or sensitive information first)?)

kwin_supportinformation.txt kwinrc.txt

One thing I noticed in the Kwin support information is this

Screen 0:
---------
Name: DVI-I-1
Geometry: 1680,0,1920x1080
Scale: 1
Refresh Rate: 59.9543

Screen 1:
---------
Name: HDMI-0
Geometry: 0,30,1680x1050
Scale: 1
Refresh Rate: 60

The refresh rate for screen 0 is wrong here. Kwin doesn't seem to know that the monitor is running at 144 Hz right now

tildearrow commented 5 years ago 
Painting blocks for vertical retrace:  no

...what? How is it "no"? kwin-lowlatency always blocks to wait for VBlank. How did it come up with "no"?

Can you try setting the VSync mechanism to "SGI video sync with horrible hack" and reporting the output of qdbus org.kde.KWin /KWin supportInformation again? This may be the culprit.

tam1m commented 5 years ago

Wow... I just realised GLPreferBufferSwap=n in kwinrc aka "Tearing Prevention ("vsync")" was set to "Never" the whole time. Which is strange, because I never touched that setting. My problems started right after the update to 5.16.5. Only then did I even open the settings. Did you try to reproduce the bug with my kwinrc? After setting it to "Automatic" things are working. Although, I do get a lot of tearing right now! I don't really have the time to look into it at the moment, but it might be unrelated to this issue(?).

Is kwin_lowlatency "breaking", when vsync is completly off, intended behavour? I feel like, it must have been working fine before, since my configuration did not change at all. Just updated to the latest version and that was, when things began to break.

This was also the reason for Painting blocks for vertical retrace: no

tildearrow commented 5 years ago

Wow... I just realised GLPreferBufferSwap=n in kwinrc aka "Tearing Prevention ("vsync")" was set to "Never" the whole time.

If that's the cause of this bug, then that's still unusual...

Although, I do get a lot of tearing right now!

Try enabling "Sync to VBlank" in your NVIDIA settings? I see they're turned off.

tam1m commented 5 years ago

If that's the cause of this bug, then that's still unusual...

This is definitely it. As soon as "Tearing Prevention" this is set to "never", things stop working.

slartibart70 commented 4 years ago

Hi, this problem is especially annoying with websites of banks (in germany) displaying a so called 'flicker-code' that you must read with a special external device from screen to generate a banking-transaction number (see: Sm@rtTAN plus) Having the default setting (tearing prevention: automatic), the device won't reconize the code. Setting it to 'off' or 'only when cheap' fixes the problem with the flicker codes for now. Is it possible to have those settings for selected applications only? (btw, this was on a laptop with intel graphics)

tildearrow commented 4 years ago

Sorry. No time. Fixing when I can

prefanatic commented 4 years ago

@tildearrow

This has become 100% reproducible for me since the 5.18 update. Before, it would only appear when I had very few, if any, windows opened. Since 5.18, all animations run at extremely slow speeds.

This is using the 'none' vsync mechanism, using nvidia 440.48.02.

Using the SGI video sync hack mitigates the issue.

tildearrow commented 4 years ago

@prefanatic Time to switch to the NVIDIA card and test... but... "SGI video sync hack"? Do you mean the SGI video sync or SGI video sync with horrible hack?

prefanatic commented 4 years ago

@tildearrow

With the "horrible hack". The last option in the list of vsync mechanisms.

tildearrow commented 4 years ago

I can't fix this for now.... I have no time and I am not feeling happy so, yep...

I have temporarily set it to horrible hack by default on 5.18.2... until I figure out what causes this problem...

tildearrow commented 4 years ago

Oops, sorry. Wrong label.

realnc commented 4 years ago

Check if you have triple buffering enabled. Enabling it can cause weird issues.

$ cat /var/log/Xorg.0.log | grep TripleBuffer

What does this print?

Also check whether you have exported environment variables that were popular in the past to fix kwin nvidia bugs, like KWIN_TRIPLE_BUFFER or __GL_YIELD. They can also cause issues.

prefanatic commented 4 years ago

@realnc

I've not enabled triple buffering, nor exported those two variables.

@tildearrow

I updated to 5.18.1 (https://github.com/tildearrow/kwin-lowlatency/commit/697c7eff129171432428ca0dbc249011a8fcab4a) a couple days ago, have not reproduced it since. It seemed to only crop up for 5.18? Works perfectly fine right now.

tildearrow commented 4 years ago

@prefanatic Wait how? OK, I got to look at this when I come back home.

In the meanwhile, can you tell me if this issue reproduces with the SGI video sync VSync mechanism?

prefanatic commented 4 years ago

@tildearrow

The issue does not reproduce with the SGI video sync mechanism.

I've taken time to drop back down to the first implementation on 5.18.0, and am unable to reproduce it again. Incidentally, I forgot I've since updated my nvidia drivers from 440.48.02 to 440.59. Maybe that's a factor here.

I may not be able to tonight, but I'll drop back down to 440.48.02 and see if I can get it slow again there.

realnc commented 4 years ago

I got this slow animation issue while testing the various "vsync mechanism" settings on 5.18.2 due to bug https://github.com/tildearrow/kwin-lowlatency/issues/63. The issue disappeared after restarting kwin with kwin_x11 --replace &.

To me it looks like some kind of settings issue rather that an issue with nvidia drivers. If you're still on 5.18.0, try changing that setting without restarting kwin and see if you can trigger the behavior. Then try current master branch (there's a settings initialization fix after the 5.18.2 release) that might have fixed it without the need to restart kwin.

tildearrow commented 4 years ago

@prefanatic Amazing! It's good to see that mysterious issue g-

@realnc ...oh no, not again... :< Sorry I got no time now due to class and because the NVIDIA driver stopped working somehow (probs 'cuz I have AMDGPU-PRO installed and that conflicts somehow) but after I am done I need to look at this.... either at night or midnight when I am free.

In the meanwhile can you try removing the __GL_MaxFramesAllowed code in plugins/platforms/x11/standalone/glxbackend.cpp and use the SGI video sync mechanism and report if that fixes the issue? I have a feeling this might be....

tildearrow commented 4 years ago

Here:

https://github.com/tildearrow/kwin-lowlatency/blob/7e708d73565d904b39ee06eac74ae3c6ce1c2f2d/plugins/platforms/x11/standalone/glxbackend.cpp#L122

realnc commented 4 years ago

Great. Now I can't reproduce it no matter what >.< The closest I've gotten to is triggering a state where I get very slow scrolling in Firefox when I mess with the GLPreferBufferSwap setting in kwinrc, which is fixed by restarting Firefox. However, this also happens with vanilla kwin so it's irrelevant here.

As for the half vsync issue when using the "horrible hack" setting, commenting out that line indeed prevents it from happening.

tildearrow commented 4 years ago

@realnc According to the original reporter, it would not reproduce under normal KWin.

realnc commented 4 years ago

Different issue. Shouldn't have mentioned it then.

tildearrow commented 4 years ago

Ugh, have tried for a fair amount of time and could never reproduce the issue... :< I really don't know what could cause it anymore...

tildearrow commented 4 years ago

Slightly reproduced under AMD by using "None" VSync mechanism and VSync set to Never. I don't know if this is related.

Myned commented 4 years ago

I am able to reproduce the slowed animations on my system:

Manjaro KDE 5.18.5 w/ Liquorix kernel GTX 1060 3GB w/ nvidia-beta-dkms 440.82 driver kwin-lowlatency 5.18.5-3

Tested with Show FPS and Wobbly Windows Desktop Effects, as well as testufo on Vivaldi

kwinsupportinfo kwinrc kwin-lowlatency settings that work, but causes OBS artifacts due to requiring Allow Flipping (Force Composition Pipeline is also required to prevent slow animations)

Some notes, including a table of the notable options and their effects:

Table Tearing prevention | VSync mechanism | Force Composition Pipeline | Allow Flipping | No tearing, stutters, or slowdowns | Notes --- | --- | --- | --- | --- | --- Never | None | ✓ | ✓ | ✓ | Flipping causes flickering in OBS Never | None | ✕ | ✓ | ✕ | Slow animations Never | None | ✓ | ✕ | ✕ | Slow animations Never | None | ✕ | ✕ | ✕ | Slow animations, previously worked without issue Automatic | None | ✓ | ✓ | ✓ | Flipping causes flickering in OBS Automatic | None | ✕ | ✓ | ✓ | Flipping causes flickering in OBS Automatic | None | ✓ | ✕ | ✕ | Stuttering Automatic | None | ✕ | ✕ | ✕ | Tearing Never | SGI w/ horrible hack | ✓ | ✓ | ✕ | Half-sync Never | SGI w/ horrible hack | ✕ | ✓ | ✕ | Tearing Never | SGI w/ horrible hack | ✓ | ✕ | ✓ | Causes issues when using power save features Never | SGI w/ horrible hack | ✕ | ✕ | ✕ | Tearing Automatic | SGI w/ horrible hack | ✓ | ✓ | ✕ | Half-sync Automatic | SGI w/ horrible hack | ✕ | ✓ | ✕ | Half-sync Automatic | SGI w/ horrible hack | ✓ | ✕ | ✕ | Half-sync Automatic | SGI w/ horrible hack | ✕ | ✕ | ✕ | Half-sync
tildearrow commented 4 years ago

OK, so it appears this issue is in fact caused by disabling VSync as this reproduces under AMD too.

tildearrow commented 4 years ago

Successfully reproduced when trying to open a combo box. It appears that the animation timer goes crazy when we're rendering too fast (e.g. no vsync). Let's try a sort-of fix.

tildearrow commented 4 years ago

Please try commit 7afcdf0e4. This is a workaround.

tildearrow commented 4 years ago

Wait, no, please do not try. I made a mistake.

tildearrow commented 4 years ago

OK, everything fine. Please try with d76fb9af8503958dccd8164128d132455af4df0d and report back.

tildearrow commented 4 years ago

KWin-lowlatency 5.19.1 released with a possible workaround...

tildearrow commented 2 years ago

Closing as the rewrite changed everything. Reopen if it still occurs.