Bug 293274 - V-Sync doesn't work unless 'show FPS' effect is enabled
Summary: V-Sync doesn't work unless 'show FPS' effect is enabled
Status: RESOLVED DUPLICATE of bug 309512
Alias: None
Product: kwin
Classification: Plasma
Component: scene-opengl (show other bugs)
Version: 4.8.0
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-04 09:53 UTC by Luke
Modified: 2013-01-18 19:52 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Luke 2012-02-04 09:53:25 UTC
Version:           4.8.0 (using KDE 4.8.0) 
OS:                Linux

Hi, I just discover something if I enable 'Show FPS' along with other effect moving windows becomes smooth again. If 'Show FPS' is disabled tearing occurs. I thought it was nvidia misconfiguration after upgrade to 4.8 but It turns out that nvidia-settings and my eyes are fine, V-Sync actually stopped working. (V-Sync is also enabled in desktop effects KCM)

As always, up-to-date Arch Linux (x86_64 )

Reproducible: Always

Steps to Reproduce:
Enable compositing (don't know if it makes difference but mine issue is on nvidia proprietary drivers). Move some window around - tearing. Enable 'show FPS' effect - no tearing.


Expected Results:  
No tearing.
Comment 1 Thomas Lübking 2012-02-04 15:59:18 UTC
the showFPS effect just repaints the entire desktop as fast as possible, ie. causing fullscreen repaints.

nvidia-settings, OpenGL settings. Is "Sync to VBlank" checked?
Comment 2 Luke 2012-02-04 19:42:50 UTC
"Sync to VBlank" in nvidia-settings naturally is checked, along with triplebuffer in xorg.conf, what else should I do? It's not my desktop but if I recall correctly it was tear-free in 4.7.x
Comment 3 Thomas Lübking 2012-02-04 20:19:41 UTC
uncheck it - you're syncing twice (and i don't know what happens then aside a dropping framerate)
You must restart kwin after changing the setting (or log out/in)

The nvidia global syncing alongside the triple buffer is a great feature (better than any client syncing could be) but only applies to glSwapBuffers() what's usually not used by kwin (the frontbuffer is only partially updated) but is when the showFPS effect causes full screen repaints (so here the nvidia mechanism kicks in)

the environment variable "__GL_SYNC_TO_VBLANK" overrides the global setting so use it to either disable it for kwin or enable it for certain games (which will profit, but you must turn off the game internal syncing - i however assume that the driver will do that anyway and therefore effectively disables the sync call inside kwin)
See the nvidia README for details. (esp. in context with twinview if you use several screens)

the vsync code in kwin has btw. not changed between 4.7 and 4.8
Comment 4 Luke 2012-02-05 15:57:43 UTC
I've disabled synk "to v-blank" in nvidia-settings, not much of improvement, the whole situation could be because this particular PC is hooked up to HDTV with custom EDID (because of nvidia bug) - I just noticed that tearing occurs just on top part of screen, moving windows lower is fine (not fluid as with fps effect but no tearing). If I get a chance I'll try test it on a different display. Anyway question is: is it possible to achieve smoothness on windows move which I can taste with fps effect enabled? Because it feels sooo much better.
Comment 5 Thomas Lübking 2012-02-05 16:14:31 UTC
Presumingly only by generally forcing full repaints glSwapBuffers() and by this activating nvidia driver syncing and drop all custom sync attempts.

It's however no way an option for most other chips (ie. intel would suffer a LOT from this, as most integrated chips would because of the poor RAM speed) so we'd need a distinct nvidia render path, BUT:

I know this "tearing occurs just on top part of screen" what is -from what i've seen on a video- not "tearing" at all. The top section hangs behind the rest of the image for a considerable time amount, right?
(it was more than just one frame on that video, more like 10 frames @ 60Hz ie. ~166ms)

I think it was on an external screen from a monitor (only) as well, can you confirm this?
("tearing" is just nasty. You see it on very slow horizontal moves @ low fps (in a video) where the lower part is one frame behind the upper and it takes 25ms for the update. The split position is random and often walks across the screen, making the display a bit uncalm)

Is the "tearing" on your side the very same 
- with the XRender backend?
- without v'sync enabled?
Comment 6 Luke 2012-02-05 21:06:18 UTC
with XRender backend it tear but in different way than with OpenGL - with faster moves it tear stairs-like on whole side border of the window (same as with opengl but without v-sync in kcm), with openGL and v-sync in kcm it just tear in one place/small area (moving over upper part of display) but more noticeable, even on slower moves

it doesn't matter if vsync is enabled or disabled in nvidia-settings
Comment 7 Stefan Lithén 2012-07-30 16:59:52 UTC
I have the same problem. My graphic card is an Nvidia Geforce 2500 GT.
I have a big monitor with 2560x1600 pixels res.

In Gnome/Unity with compis things goes smooth but in KDE 4.8 (ubuntu 12.04) I get lagging/tearing when moving windows.

Enabling the "Show FPS" effect makes it go smooth (even though sometimes the frames can drop a bit).

I'm getting a much newer/faster nvidia card tomorrow so I will/can do more tests then.
Comment 8 Luke 2012-08-14 20:06:20 UTC
OK, I don't know what was the solution but after couple of upgrades recently I can't reproduce it anymore! :) Anyone can confirm this so we can close this bug?

nvidia 304.37 and KDE 4.9
Comment 9 Thomas Lübking 2012-10-13 18:35:57 UTC
This patch might avoid tearing IN FULLSCREEN WINDOWS ONLY
The more feedback we can get on it, the more likely it'll get into the next release.

https://git.reviewboard.kde.org/r/106833/
Comment 10 Martin Flöser 2013-01-18 19:52:04 UTC
setting to duplicate of newer bug report

*** This bug has been marked as a duplicate of bug 309512 ***