a) proper detection of nvidia GPU refreshrate should be provided in 4.6
b) by default kwin unredirects fullscreen windows (ie. they're not composited) for performance reasons ("kwriteconfig --file kwinrc --group Compositing --key UnredirectFullscreen true", 4.6 has a GUI checkbox), so there should not be any kwin related tearing in this mode anyway
c) to set a fixed refreshrate for and matching nvidia GPUs do
kwriteconfig --file kwinrc --group Compositing --key RefreshRate `nvidia-settings -t -q RefreshRate | cut -d "," -f1`; qdbus org.kde.kwin /KWin reconfigure
d) disable blurring and check whether general performance improves on this, but please do not turn this bug into "kwin is slow (with nvidia)", there're several other reports in this regard...

notice that this will hardcode the refreshrate and you'll have to remove it later on to get the proper refreshrate dynamically (unfortunately there seems no "delete" in kwriteconfig, it's in ~/.kde/share/config/kwinrc, group [Compositing])

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

Hi there,

Tried the solution above to fix the refresh rate, but the video kept tearing. Sure I dont want to transform this as slow nvidia etc etc, but the problem is still the same. Also 4.6 is at least a month away, and even more for Debian. What else can I do to help?

Questions:
a) does the video really "tear" (miss-sync) or rather "stutter" (performance)?
b) does it also occur in fullscreen playback mode?
c) is it limited to "HD" videos?

Notes:
a) if the above refreshrate hardcoding doesn't fix it, 4.6 will unlikely do
b) please notice that there's no way to sync XRender, you have to use the GL backend to make vsync have any impact

Request:
please attach your ~/.kde/share/config/kwinrc

Created attachment 54372 [details]
kwinrc

I have exactly the same problem. I was able to remedy it in Gnome by enabling vertical sync in Compiz and manually setting the refresh rate to 60 Hz. This does not work in KDE, I have tearing in full screen mode and in windowed mode.

The only way to avoid the problem in KDE is to 1) disable desktop effects, 2) view video in VLC using the OpenGL backend. When desktop effects are on, no luck. I also tried forcing the refresh rate using kwriteconfig, it changed nothing.

I also only have the problem on an external screen. some specs:
GPU: NVidia NVS 3100M 256 MB
Driver version: 260.19.21
KDE 4.5.85 (4.6 Beta2)
Screen connected via DisplayPort->DVI adapter

I made some samples which show the tearing clearly when present, they are from a copyrighted TV show, but very short and no audio, so I think it's fine:
http://www.fa2k.net/test.mpg http://www.fa2k.net/test2.mpg

Please tell me if there is anything I can do to help debug this

hmmm... kwin should be unredirecting fullscreen windows, ie. compositing doesn't take place when playing back videos *fullscreen* (NOT maximized), so kwin vsyncing has no impact at this moment (unless debian patched the default), try:
   kwriteconfig --file kwinrc --group Compositing --key UnredirectFullscreen true
to force a known value on this (but it is the default)

other than this - on a locale issue:
   kwriteconfig --file kwinrc --group Compositing --key RefreshRate
`nvidia-settings -t -q RefreshRate | cut -d "." -f1`; qdbus org.kde.kwin /KWin
reconfigure

would write the actually proper entry (60 instead 60.00) and (sorry, didn't mention that) it oc. only detects the proper refreshrate of the _current_ (main) device (so you need to do this after changing displays)

However, it seems that fullscreen playback tearing should be unrelated to kwin =\

Notice that xv can (usually*) NOT be synced, so playing unredirected videos might cause tearing (but then you should encounter tearing with suspended compositing either... makenosense..)

*the nvidia css driver allows you to sync the xv video and/or texture adaptor and you can also explicitly pick one in better players (s/mplayer, probably vlc) - but i do not know whether this feature is prohibited while a compositor is running (though the client itself is not redirected)

Compiz afaik doesn't unredirect fullscreen windows, so maybe you actually have to turn off unredirection to get rid of tearing with enabled compositing + vsync, but this will cost performance

---

About the testvideos: i dropped a note to the MPIAA ;-P
I get notable tearing in xrender compositing (what is unavoidable, but not active on your side) but not in gl compositing (+vsync, +hardcoded rate in vanilla 4.5.4) or unredirected playback (mplayer -fs test.mpg)
To sync the xv adaptors, check nvidia-settings, "X Server XVideo Settings", i use the video blitter, but the texture blitter should work ok as well (you just need to pick it)

Hi,

Thanks for the quick reply!

> --- Comment #6 from Thomas Lübking <thomas luebking gmail com>  2010-12-10 00:13:04 ---
> hmmm... kwin should be unredirecting fullscreen windows, ie. compositing
> doesn't take place when playing back videos *fullscreen* (NOT maximized), so
> kwin vsyncing has no impact at this moment (unless debian patched the default),
> try:
>    kwriteconfig --file kwinrc --group Compositing --key UnredirectFullscreen
> true
> to force a known value on this (but it is the default)
> 
Done, i set it to true. Strangely, I still get tearing when using OpenGL
fullscreen in VLC. Maybe VLC doesn't use the proper fullscreen API.

In GMplayer, I get:
       | full screen | window |
gl     |   OK        |  x     |
xv     |   x         |  x     |

(in the table x means tearing artifact)

> other than this - on a locale issue:
>    kwriteconfig --file kwinrc --group Compositing --key RefreshRate
> `nvidia-settings -t -q RefreshRate | cut -d "." -f1`; qdbus org.kde.kwin /KWin
> reconfigure would write the actually proper entry (60 instead 60.00) and (sorry, didn't
> mention that) it oc. only detects the proper refreshrate of the _current_
> (main) device (so you need to do this after changing displays)

I ran the command now & logged out and back in, it didn't change
anything for the video, but it changed the setting to 59 Hz.

The refresh rate is
reported as 59.95 Hz in nvidia-settings. It's possible to force it to 60
Hz, but that doesn't change anything, and it's still reported as 59.95
in other places in nvidia-settings.

> 
> However, it seems that fullscreen playback tearing should be unrelated to kwin
> =\
> 
> Notice that xv can (usually*) NOT be synced, so playing unredirected videos
> might cause tearing (but then you should encounter tearing with suspended
> compositing either... makenosense..)
> 
> *the nvidia css driver allows you to sync the xv video and/or texture adaptor
> and you can also explicitly pick one in better players (s/mplayer, probably
> vlc) - but i do not know whether this feature is prohibited while a compositor
> is running (though the client itself is not redirected)

> 
> Compiz afaik doesn't unredirect fullscreen windows, so maybe you actually have
> to turn off unredirection to get rid of tearing with enabled compositing +
> vsync, but this will cost performance

This had the effect of introducing the tearing in full screen gl output
with mplayer, making it the same as for windowed mode (as expected).

There is something that goes wrong with the syncing in kwin; if one
could fix this somehow, then I could enable UnredirectFullscreen and
everything would be fine, maybe a bit slow.

> active on your side) but not in gl compositing (+vsync, +hardcoded rate in
> vanilla 4.5.4) or unredirected playback (mplayer -fs test.mpg)
> To sync the xv adaptors, check nvidia-settings, "X Server XVideo Settings",

I have tried with this one both on and off, and also the sync setting
under OpenGL settings.

> i
> use the video blitter, but the texture blitter should work ok as well (you just
> need to pick it)

Sorry, didn't understand that last part.

Hope this helps (i'm afraid it will not.. ).

Cheers,
Marius

PS: another video that is good for testing
http://www.youtube.com/watch?v=FavUpD_IjVY

Ok, status update after some deeper inspection and nvidia research (ie, i read the README and the forum ;-)

a) __GL_SYNC_TO_VBLANK=1 (or the general GUI setting) won't work at all, because it only intercepts glXSwapBuffers, what is only used during fullscreen effects to save bandwidth. I enforced using glXSwapBuffers, set the env and any kind of kwin related tearing semmed gone (so this would actually be a way, but glXSwapBuffers is probably no option for the "weaker" -ie. integrated- GPU fraction) but that was before the below, whether it really works (i however guess so) needs to be retested.

b) kwin's syncing code is broken to the ground =)
I'll add a review request later on, but in short:
currently the RefreshRate has no major impact at all. Compositing is more or less constantly performed in a "while true" loop and then artificially delayed by a post check that delays it by 1ms (i noticed that when playing with the refreshrate, even "1" had no impact on the video playback, ran constantly at 23.976 fps, the comment for the lastCompositePaint QTimer is nonsense, Qt doesn't fire a timer as often as possible, unless oc you set the timeout to "0"...) and the glXWaitVideoSync call if v'syncing, of course.
In addition it uses the Qt signal/slot mechanism, which is very convenient and powerful, but not the optimal choice for time critical actions ;-)

c) Now unfortunately, replacing the signal/slot stuff and fixing the internal timer delay made the tearing somewhat reliably reproducable (appears constantly at realistic framerates, more or less vanishes when faking the former behaviour with RefreshRate=999), but didn't fix it.

Nvidias mantra seems (and may very well be) that glXWaitVideoSync is ("shit") because it blocks and the GL client process can get too many interrupts if other processes suck CPU (like a video player) and therefore the front buffer cannot be completely updated (esp. not not using glXSwapBuffers) before the following vblank...(thus having the driver sync to vblank is better) - that however doesn't sound realistic in our case and would also not explain why tearing started to scale with an effective RefreshRate for me =\

There's probably still sth. wrong (even with my new code ;-) - i'm gonna search on...

thanks for the good investigation and that matches what I feared :-( I noticed that something is broken on ES, where I always do eglSwapBuffer. it's fine for normal compositing, but as soon as a fullscreen effect is running KWin starts to go crazy on CPU usage. Your investigation can confirm that behavior. Looking forward to the review request.

I would also like to thank Thomas Lübking for looking at this. It's not
all kwin's fault though, NVidia is the one that intentionally uses a
fake refresh rate on external displays. Of course, it would be great if
one could work around this in KDE.

I have to admit, I went to the dark side (Gnome) because of a different,
more serious bug, but I hope to come back to KDE ASAP :) It's still just
a few clicks away, if you need some info.


Marius


On 13/12/10 07:09, Martin Gräßlin  wrote:
> https://bugs.kde.org/show_bug.cgi?id=258971
> 
> 
> 
> 
> 
> --- Comment #9 from Martin Gräßlin <kde martin-graesslin com>  2010-12-13 07:09:56 ---
> thanks for the good investigation and that matches what I feared :-( I noticed
> that something is broken on ES, where I always do eglSwapBuffer. it's fine for
> normal compositing, but as soon as a fullscreen effect is running KWin starts
> to go crazy on CPU usage. Your investigation can confirm that behavior. Looking
> forward to the review request.
>

Running on a newer nvidia GT 435M on HDMI to the external monitor makes the effect a little better, but still noticeable when fullscreen. But I'm glad to see that the problem is being seriously investigated! Thank you guys. 

BTW, is there a way to report this problem to NVIDIA so they can fix this?

Fullscreen windows are by default not composited, ie. your video player tears.

-> Activate xv syncing in nvidia-settings or switch the player backend to eg. GL (and have it sync or enfore syncing by exporting __GL_SYNC_TO_VBLANK=1 before running the player (and hope it uses glXSwapBuffers)

I'm not sure whether vdpau can currently be sync'd.

SVN commit 1207577 by luebking:

commiting http://svn.reviewboard.kde.org/r/6120/#review9304
this should improve v'syncing, maybe v'synced "smoothness"
remaining and exposed issue are "dirty textures" w/o damage events (see the requst description)
can be diminished by increasing MaxFPS above the fastest update (or shadowed below the slowest one)
CCBUG: 258971


 M  +32 -37    composite.cpp  
 M  +4 -1      options.cpp  
 M  +1 -0      options.h  
 M  +23 -2     scene_opengl.cpp  
 M  +2 -0      scene_opengl.h  
 M  +2 -2      workspace.cpp  
 M  +4 -4      workspace.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1207577

With this last commit my desktop becomes a lot more sluggish with composite enabled, and all refreshes are out of sync :( Reverting kwin to revision 1207576 fixes the problem.

I'm using KDE trunk compiled with kdesrcbuild on Debian Lenny/Sid, AMD64 architecture, NVidia GeForce GTX 260 video card, drivers 260-19-21 from debian repo, XOrg 7.5+8.

Also, i didn't notice any tearing playing videos before last commit.

"all refreshes are out of sync" sounds like a wrong fefreshrate.
a) define all (on what kind of actions do you observe "what")
b) do you have a hardcoded RefreshRate entry? does it match your screen?
   "kreadconfig --file kwinrc --group Compositing --key RefreshRate"
c) if not, run "kdebugdialog", filter "1212" activate kwin debugging, run kwin from a terminal (konsole) and watch for the detected refreshrate (grep -i rate). does it fit?

d) run "kwriteconfig --file kwinrc --group Compositing --key MaxFPS 60", suspend/resume compositing. Maximum is capped at 1000.
The default is 35(Hz) and actually should be sufficient, please elaborate on "sluggish" (scrolling, moving, video playback?)

a) plasma animations and windows movements are not "fluid". seems that animations are rendered with a low FPS rate. Switching from QT_GRAPHICSSYSTEM 'raster' or 'opengl' to 'native' help a lot, but moving windows tearing occurs.

b) No. I also tried to start kde with a clean KDEDIR, without success.

c) Yes, it fit. i have a 60 Hz monitor, and kwin says:
KWin::currentRefreshRate: Refresh rate  60 Hz

d) tried to set MaxFPS to 60, but tearing still present moving windows. Videos in fullscreen mode are not affected (tried smplayer with vdpau, and dragonplayer).

if it could be helpful, at NVidia X Server Settings i have these flags enabled:
X Server XVideo Settings --> Sync to VBlank
OpenGL Settings --> Sync to VBlank

I got exactly the same problem as Marco described after upgrading from 4.5.85 to 4.5.90. All kwin "animations" (or even window movements) seemd to be slow and choppy (far from the smoothness I got in previous KDE releases - including 4.6 beta2). I've got sync to VBlank enabled in nvidia-settings (for both xv and ogl), and VSync disabled in kwin. Luckily, setting MaxFPS=60 helped tremendously with this animation smoothness (they are not as choppy), but I still get a feeling, that things don't run as smoothly as with beta2. I always had tearing with smplayer in windowed mode (fullscreen always worked fine for me - and still does now), and with kwin from RC1 this tearing is still there. But for instance scrolling a web page in chrome browser seemed to be smoother (without noticeable tearing) in beta2. Dunno - maybe I'm imagining things :/ Since I'm using kde rc1 from opensuse repos, I don't have a easy way to go back to older kwin release to really confirm it). BTW with current changes in kwin, what are the recommended settings regarding vsync for nvidia users ? Should I enable opengl vsync in nvidia-settings or kwin (turning it on in both of these places causes very noticeable slowdowns)? 

My system info:
OpenGL renderer string: NVS 3100M/PCI/SSE2
OpenGL version string: 3.3.0 NVIDIA 260.19.29
X.Org X Server 1.8.0

you should NOT activate global vsyncing in nvidia-settings if you intend to use a composited system, it has no effect most of the time.
this is regardless of any changes unless kwin starts to repaint the entire screen on each frame (using glXSwapBuffers, which is intercepted by the driver to align it to the vblank signal. since the driver is better in doing this than a client, we'd then silently activate this driver feature for the kwin process under the hood)

You can increase MaxFPS as much as you want (to get more smoothness).

Since i'm pretty stupid (sorry, but it's my parents fault ;-) I managed to re-introduce the very same error i had removed in another place.
Please try the attached patch to deal with the vsync situation.

Notice that there's some kind of "block tearing" if you've two intersecting  windows (not necessarily on the same virtual desktop) at significantly different refreshrate (the reason seems to be that the texture is invalidated quite some time before sending a damage event). This is easily seen by placing a terminal with mplayer output under a tear prone video - and it's not "tearing" that could be fixed by syncing to the display refreshrate.

Other than this, i'm now gonna try some other vsync strategies that allow to unconditionally call glXWaitVideoSync w/o to many time loss on the frame....

Created attachment 55201 [details]
complementing time...

Patch applied and kwin recompiled. helps a little bit, but the problem remains moving windows and playing videos in windowed mode.
I've also disabled all vsync options from NVidia Settings, letting it checked only in kwin.
what additional hardware/software info could be helpful?

We have to consider reverting the change, if we don't get it fixed before 4.6 RC2.

I hope we can find out what causes the trouble and see if it is just caused by some settins.

Therefore could you please try to use a new user to verify that no custom settings are causing the issue?

As for me, after applying patch from comment #19 and setting MaxFPS=180 I get about the same "smoothness" as I experienced with previous kwin versions. I tried with new account, and it's the same story - unless I bump MaxFPS to atleast 60, all window movements or animations (window scale in, minimize, present windows) are very choppy. To be honest, if those latest changes in kwin were supposed to bring some improvements with vsync, then I'm afraid they somehow not show up on my system. There is still quite visible tearing when playing a video in (s)mplayer in windowed mode using opengl output (just like in previous kwin versions). In fact, I don't see any difference between having vsync enabled or disabled in kwin config. Like I mentioned previously, I haven't used "kwin's vsync" in previous releases, so I can't say how it performed before. Don't know if it's important or not, but when I have vsync enabled in kwin (and MaxFPS=60), and I launch glxgears, it shows, that it renders more than 1500 frames per second, where if I had vsync enabled in nvidia-settings, it always showed no more than 60fps (which I also would expect when using kwins vsync).

(In reply to comment #22)
> launch glxgears, it shows, that it
> renders more than 1500 frames per second, where if I had vsync enabled in
> nvidia-settings, it always showed no more than 60fps (which I also would expect
> when using kwins vsync).

No, that is "normal" and expected. Glxgears only prints how often it can swap buffers, that's not related to what happens to the redirected window or how often it will be painted.
Since __GL_SYNC_TO_VBLANK=1 (or the checkbox in nvidia-settings) will intercept and limit glxgears' buffer swapping, glxgears will then figure it's own framerate. There's no connection to the GPU framebuffer.

Created attachment 55215 [details]
new old vsync strategy

Attached is a patch (against plain RC1) that reverts the strategy to "jump ahead the next vsync and wait" - just actually does that.
Also the default MaxFPS is now 60Hz and will be increased until it multiplies your refreshrate.

-> WARNING: The patch will paint a lot of dbug numbers.

Therefore it will bloat your ~/.xsession-errors if do do not run it from a terminal or will spam this terminal with constant output. (until you suspend compositing)
Debug statements are in composite.cpp:442 & scene_opengl.cpp:808, comment them if you want to regularily use the patch! I mean that. ;-)

The "error" is how much we miss the rendering time of this frame (estimated from the last rendering time amount) the other number is INTERESTING and hints how long we waited for the vsync - you want this number to be small. (60Hz would be 16.66ms)

Given the imprecision of the timerbased syncrate calcualation i figured during debugging this (i sometimes get vsync timeouts far above my refresh rate), i guess the "only wait if we think we have to" strategy was doomed from the beginning on, sorry everyone :-(

Created attachment 55228 [details]
ensure minimum fps interval >= vblank interval

jaja, the pitfalls of modulo calculations.
for the former bug, ensure that your MaxFPS is smaller than the screen refreshrate - or just apply this one...

Hello im Nece228. Since upgrading to KDE 4.6 rc1 from beta2 i experienced tearing (when vsync is enabled) and major desktop effects lagging. I can confirm that Thomas patch really solves the problems. i no longer see tearing or any kind of lag. Im using xorg-server 1.9.2, nvidia 260.19.29

*** Bug 261314 has been marked as a duplicate of this bug. ***

Just tried the patch from Comment 25 from Thomas.

I can say that compositing is much smoother than rc1.
I did a very crude benchmark, activating desktop grid and then quickly highlighting each desktop. CPU usage before 25-26%, and after applying the patch 14-17%. I know this probably means nothing however :P

Hello. Since upgrading to KDE 4.6 rc1 from beta2 I I've also had problems with desktop effects lagging. I can confirm also that Thomas patch really solves the problems. nvidia 260.19.29 on GeForce 9600M GT ubuntu maverick.

Created attachment 55298 [details]
error.log

Hey Thomas, I've tried the patch from comment #25. If your interested, I've attached my "error" log in above comment (which I accidentaly posted without this info). Anyway, after this patch, kwin seems to run like in previous beta builds even without manual editing of kwinrc (on new user account) - probably a result of bumping up a default MaxFPS to 60 ;) . As for tearing - still happens, also just like it was doing with previous kwin betas/stable releases.

It's for sure tearing, because vsync isn't active (i can see this from the error output - was about to ask ;-) what brings us to the interesting question:
   "why?"

possible reasons:
a) you're using the xrender backend
b) you're using indirect rendering
c) you haven't enabled vsync
d) your driver/GPU does not support glXGetVideoSync
(did it fell off a truck? ;-P
do "glewinfo | grep -i videosync" or "glxinfo | grep -i videosync")
e) glXGetVideoSync( &sync ) or glXWaitVideoSync( 1, 0, &sync ) do not return "0"
(scene_opengl.cpp:165ff)

if you can rule out a-d as source of the issue, you'll have to patch the code for debug output. call for assistance if you need.
(though kwin should really yell a debug output or even warning in this case, gonna patch here as well)

Created attachment 55300 [details]
vsync_enabled_error.log

D'oh! I've attached the wrong file (that log was taken, when vsync was disabled in kwin). Here is the right one (taken with vsync on). I was comparing the tearing "quality" between vsync on and off. That latest patch seem to make some difference - tearing is not as strong, but still very noticeable, and quickly makes one switch to fullscreen whenever possible ( like when playing a video in (s)mplayer ).

Post #25 patch really helps with the new Kwin "issue", no weird lag.

(KDE 4.5.90, Archlinux x86_64)

SVN commit 1210445 by luebking:

revert vsync strategy, fix timeouts
differecens to patch atteched to 258971:
- removed debug statements
- fixed indention...
- NON vsync strategy does not rely on the estimation, but on the time passed since the last repaint trigger, allowing a precise framerate

CCBUG: 258971



 M  +40 -10    composite.cpp  
 M  +1 -1      options.cpp  
 M  +2 -0      scene.h  
 M  +2 -0      scene_basic.cpp  
 M  +7 -21     scene_opengl.cpp  
 M  +0 -2      scene_opengl.h  
 M  +2 -0      scene_xrender.cpp  
 M  +0 -1      workspace.cpp  
 M  +1 -1      workspace.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1210445

SVN commit 1210450 by luebking:

backport of 1210445

revert vsync strategy, fix timeouts
differecens to patch atteched to 258971:
- removed debug statements
- fixed indention...
- NON vsync strategy does not rely on the estimation, but on the time passed
since the last repaint trigger, allowing a precise framerate

CCBUG: 258971



 M  +40 -10    composite.cpp  
 M  +1 -1      options.cpp  
 M  +2 -0      scene.h  
 M  +2 -0      scene_basic.cpp  
 M  +7 -21     scene_opengl.cpp  
 M  +0 -2      scene_opengl.h  
 M  +2 -0      scene_xrender.cpp  
 M  +0 -1      workspace.cpp  
 M  +1 -1      workspace.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1210450

(In reply to comment #31)
> As for tearing - still happens, also just like it was doing with previous kwin betas/stable releases.

Can you have a look at the comments on the review request, esp. on the "exposed" issue and ensure that the tearing you observe is NOT caused by sth. below the video?
(in doubt: shutdown plasma "kquitapp plasma-desktop" and minimize/shade all other windows. also ensure that kwin does NOT "keep thumbnails" "always")

I've already tried (s)mplayer after making sure, there are no other windows, that could cause "block tearing", that you mentioned earlier. But I found something else, that might be interesting. I noticed, that the tearing I get is not "constant" - it's not visible all the time. It looks like I can play the video, and tearing shows just for a couple of seconds interleaved with couple of seconds of tear free playback. I've messed with different mplayer options (trying different yuv modes of gl, disabling direct rendering / double buffering / vf filters, etc.), but they don't seem to make much difference. My current player config looks like this:

[default]
vo=gl:yuv=2:lscale=1
double=yes
autosync=100
framedrop=yes
#refreshrate=60
vf=eq,pp=hb/vb/dr
dr=yes
noslices=yes
#vsync=yes
ao=pulse

From what I observed though, it looks, that switching to gl2 video output in mplayer seems to be tearing much less than gl (most of the time it's not visible). Out of curiosity I launched Show FPS kwin effect. During "normal" usage (moving, opening applications windows, entering present windows mode, etc) it shows constant 60fps. When I launch mplayer (-vo gl), it shows 60fps interleaved with 30fps every couple of seconds. When it drops to around 30fps the tearing shows up. This doesn't seem to happen in (s)mplayer fullscreen mode (I don't see show fps indicator, but the video is smooth and tear free all the time). So I'm not sure if it's mplayer bug or some conflict with kwin. The frame drop doesn't happen with for instance mplayer -vo x11 or even gl2 (so framedrop doesn't explain why an occasional tearing shows up with it). I'm using mplayer version dev-SVN-r31930-4.5 (from packman repo for Opensuse 11.3 x64). I'll also mention, that at least on my setup, tearing problem is best visible when mplayer window is maximized (tear "line" almost always shows in the upper part of a played video). Here is also my kwin config regarding compositing:

[Compositing]
AnimationSpeed=3
Backend=OpenGL
CheckIsSafe=true
DisableChecks=false
Enabled=true
GLDirect=true
GLMode=TFP
GLTextureFilter=1
GLVSync=true
HiddenPreviews=5
MaxFPS=240
OpenGLIsUnsafe=false
UnredirectFullscreen=true
XRenderSmoothScale=false

Oh and something that might be relevant to the original bug report ("vertical tearing when playing videos fullscreen") - seems that using mplayer -vo gl2 causes tearing when going into mplayer's fullscreen mode (-vo gl works perfect though) - but I guess, that since in fullscreen kwin compositing doesn't have any effect (unredirected window), it may be more mplayer's fault/bug.

Errr... if you suspend/disable compositing and use the mplayer "-vo gl" in windowed mode, you should get quite some tearing - sync'd GL vo has here never worked in mplayer windowed mode, regardless of global nvidia-settings syncing.
"-vo xv" /does/ work in windowed mode (if you sync the proper xv adaptor in nvidia-settings)
Fullscreen does anyway.

If this is the case on your side, such "sync'd" video playback becomes pure luck (depending on mplayer rendering state when kwin waits for the sync signal) - try to set MaxFPS below the video fps (eg. 19, 20 would be next vsync rate and is automatically chosen) -> sync'd ... and soo "1910"ish ;-)

other than this:
----------------
vo=gl:yuv=2:lscale=1
-> yuv=1 is faster, no notable visual impact. you can then drop lscale

double=yes
-> is default

autosync=100
-> not vsync related and unless you've _really_ hefty A/V sync issues, 100 is faaaaar too high (try 2, 0 if you don't play buggy videos or have performance issues)

dr=yes
-> NO, not until you've working video and especially NOT with synced xv output! (causes weird lags and prevents syncing)

noslices=yes
-> be aware that it doesn't apply to all codecs and is rather a performance thing, check whether it gets you some ;-)

#vsync=yes
-> (despite commented :-) gl:swapinterval=1 (default, "vsync" is for "-vo svga", which you're not gonna use ;-)

ao=pulse
-> ieeehh ;-)
(try alsa if you've constant A/V sync issues and don't require per application volume)

> Errr... if you suspend/disable compositing and use the mplayer "-vo gl" in windowed mode, you should get quite some tearing

Hmmm... seems my system is "special" as I get the opposite behavior of what you describe ;) I don't get any tearing (vo gl, windowed mode) after suspending compositing (seems I'm lucky ;) ). I do get tearing when using xv in windowed mode with compositing enabled (I've tried it also with disabled direct rendering and noslice=no), regardless of settings in nvidia panel (X Server XVideo Settings).
I just observed that tearing happens even without launching mplayer - just by moving windows. For some reason "tear line" is always visible only at the top of the screen. Here is a little video I made, that shows it:
http://underdeconstruction.net/stuff/test.avi

Quality is crappy, but tearing is perfectly visible (video taken with plasma-desktop shutdown). This tearing doesn't seem to happen with suspended compositing. I've set RefreshRate=60 in kwinrc just to be sure, that kwin uses proper refresh rate, but it doesn't change anything. Btw does this RefreshRate setting actually work ? I don't see any difference if it's set to 10 or 60 - in the former case animation is as smooth as with 60 (and show fps confirms this, by showing constant 60fps). 
This tear in the upper area of screen if also visible regardless of maxfps setting (tried 10, 60 and 240). Also seems that this "tear line" goes to a little bit lower part of the screen if I launch a mplayer movie (more CPU/GPU usage ?) So if I keep mplayer window in the lower part of the screen, I don't see tearing in the video. Bringing any window (that contains some movement) in the upper part of the screen will reveal tearing (that's also why tearing I observed with mplayer is best visible when window is maximized). Dunno if my description is clear - if not, I can try to record another crap quality video showing this "oddness" ;)

> yuv=1 is faster, no notable visual impact. you can then drop lscale

Are you sure about yuv=1 ? Mplayer help says, it's for older gfx cards ? Anyway I've always used yuv=2 or 3 and had no problems.
lscale provides a slightly better (for my taste) image quality when upscaling - one of the reasons I always prefered gl output over any other (obviously doesn't matter too much in case of HD videos).

glswapinterval=1 never worked for me, so I also never use it

> ao=pulse
> -> ieeehh ;-)

:) PulseAudio actually works like a charm for me (and alsa on my system, feeds all the audio to pulse either way ;) ) I've set autosync some time ago for don't remember what purpose ;) , and just left it there (I don't see any side effects of using it)

BTW, I'm not using your patch from comment #35 (I use the one from comment #25 without debug output).

(In reply to comment #41)
> I just observed that tearing happens even without launching mplayer - just by
> moving windows. For some reason "tear line" is always visible only at the top
> of the screen. Here is a little video I made, that shows it:

I do NOT think that what you observe here is "tearing" in the classic sense.
It's too heavy (estimating from the video and mplayer output, i'd say the upper area _at least_ 16.6ms behind the rest, what would be a complete vsync interval!)
Also a constant break is not "common" (on unsynced playback the position would be random, on a wrong framerate it would shift across the screen)

I assume, if you raise MaxFPS and turn of vsync in kwin, this "tearing" (as shown in the video) at least diminishes? (just like uncomposited?)
Also, this happens with all effect plugins turned off as well?
 
This looks more like either a bug in GL or in the region based painting (in kwin, instead of swapping buffers) to me.

> Btw does this RefreshRate setting actually work ? 
- used to do nothing
- was used to estimate whether we can paint w/o syncing in the 4.6RC1
- is now used to estimate when to slot before the next vsync wait and has no special meaning to uncomposited painting at all.

> I don't see any difference if it's set to 10 or 60 - in
> the former case animation is as smooth as with 60 (and show fps confirms this,
> by showing constant 60fps).
Yes, this would now be controlled by MaxFPS (i wanted to unlink it from the refreshrate since we're about to see more 200Hz monitors and it -usually- doesn't make sense to update the screen this fast (unless you're using 3D shutter - this moment you should turn off compositing or ensure you can paint at 200Hz ;-)

> This tear in the upper area of screen if also visible regardless of maxfps
> setting (tried 10, 60 and 240).
This has no impact. Since guessing vsync internally had err... "ungreat" outcome in RC1, it's now completely back to glXWaitVideoSync.

> Also seems that this "tear line" goes to a little bit lower part of the screen if I launch a mplayer movie (more CPU/GPU usage ?) 
Tried kruler? (how many pixels & compared to the screen height, btw?)

So if I keep mplayer window in the lower part of the screen, I don't
> see tearing in the video. Bringing any window (that contains some movement) in
> the upper part of the screen will reveal tearing (that's also why tearing< I
> observed with mplayer is best visible when window is maximized). Dunno if my
> description is clear - if not, I can try to record another crap quality video
> showing this "oddness" ;)

> Are you sure about yuv=1?
Yes.
> Mplayer help says, it's for older gfx cards?
Actually says "uses nvidia specific extension (register_combiners)

> glswapinterval=1 never worked for me, so I also never use it
gl:swapinterval=1 is actually the default and says:
  ^
"Requires GLX_SGI_swap_control support to work.  With some (most/all?) implementations this only works in fullscreen mode." =)
(but might be GPU related, my 7600 is sufficient, but not exactly new ;-)

> BTW, I'm not using your patch from comment #35 (I use the one from comment #25
> without debug output).
For vsync, it has no impact (only non-vsync will provide you the exact MaxFPS, which is btw. increased to match your refreshrate with vsync enabled)

> I assume, if you raise MaxFPS and turn of vsync in kwin, this "tearing" (as
> shown in the video) at least diminishes? (just like uncomposited?)

Exactly

> Also, this happens with all effect plugins turned off as well?

Yup

> Tried kruler? (how many pixels & compared to the screen height, btw?)

My desktop resolution is 1400x900. The "tear line" on the video I posted, shows up at around 20pixels below the top of the screen. When playing something with mplayer or when I launch google-earth, the "tear line" goes down, and jumps randomly to values from 20 to 200 - 240 pixels counting from the top (according to kruler) - so it's not in constant place anymore. 

> Actually says "uses nvidia specific extension (register_combiners)

My mplayer version says:  1: use register combiners (nVidia only, for older cards)

But whatever... I'll try/benchamark yuv=1 later on and see if it has some benefits on my system ;)

Created attachment 55526 [details]
debug info for Bart, don't use as a regular patch!

(In reply to comment #43)
> > I assume, if you raise MaxFPS and turn of vsync in kwin, this "tearing" (as
> > shown in the video) at least diminishes? (just like uncomposited?)
> Exactly

what if you turn off vsync and constrain MaxFPS to eg. 15?

> so it's not in constant place anymore. 
Hummm.
There're three posible sources:
a) kwin doesn't manage to flush the buffer within a vblank interval of ~16.6ms (what's pretty unlikely, it's just painting some rects and takes less than 1ms here)
b) (borked damage regions - but that would require a really weird behaviour t produce the one frame lag in this area)
c) an OpenGL bug.

attached is a patch that
a) disable scissors (no idea why, just guessing...)
b) adds some debug output, including the time required to flush the buffer

Created attachment 55542 [details]
kwin debug output 

> what if you turn off vsync and constrain MaxFPS to eg. 15?

Seems that this effect is gone then too.

I've tried your latest patch - disabling scissors doesn't seem to make any effect. I've attached an archive with two log files - one was taken when mplayer was playing a video, and the other one with an almost idle (only konsole window showing 'live' kwin debug ouput) kde desktop.
I also wanted to send you a video of scrolling an image in gwenview (because it nicely shows this tearing, that jumps all over the screen, and resembles more the tearing I get with vsync off), but unfortunately my camera is too slow to capture this.

no idea whether this is due to all the dbug out (remove everything but the "flushtime" one), but flush really takes some time while mplayer is active (up to 13ms) - probably too long in some cases.

One probably could detect such and suspend the following vsync delay but
a) that would jsut lead to "real" tearing
b) the time is - as mentioned - faar too long, so i'd first try to figure "why" (i'd blame the glBitmap calls, but the suggested glRasterPos2f causes artefacts here)
-> move around the "timer.elapsed()" qDebug() to figure where you loose all the time.
c) i assume turning in scene.cpp:119
if( *mask & ( PAINT_SCREEN_TRANSFORMED | PAINT_SCREEN_WITH_TRANSFORMED_WINDOWS ))
to
if (true)
solves your problem?


@Martin:
enforcing the glXSwapBuffers solves the weird "block" tearing, maybe we should ensure the backbuffer is clean and get rid of or opt in/out the "region swapping", this would also allow us to defer vsync to the driver via the environment variable...
-> do you have a lame(tm) intel chip to test whether swapping is ok on such architecture?

Yep i had this glitches on my x300mobility radeon (xf86-video-ati) with kde4.6beta2 so its not nvidia specific, I've sold this machine so i can't be any help anymore

can anyone encountering this very specific _heavy_ tearing (despite vsync is active) attempt to figure which call in ::flushBuffer() takes so much time (the entire flush takes < 1ms here...) because there's (iff at all) few chance that any "just swap buffers" solution would make it to 4.6

Thomas, I will do the testing tomorrow, and will post the results here :)

Created attachment 55878 [details]
testing code

Sorry for a delay (I'm swamped with work), but better late than never ;)
I did a flushbuffer timing test and seems to me, that this part of code:

foreach( const QRect &r, damage.rects())
{
  // convert to OpenGL coordinates
  int y = displayHeight() - r.y() - r.height();
  glXCopySubBuffer( display(), glxbuffer, r.x(), y, r.width(), r.height());
}

is taking the most time in flushbuffer. In fact it's the only part of the code, that executes longer than 1ms. I've attached SceneOpenGL::flushBuffer code that I used to check this, and with this code elapsed[0] value shows these high timings. Also it seems to me, that I don't even have to launch mplayer, to make the timings skyrocket. Even if I just move a mouse pointer around for instance dolphin file list, I see that elapsed[0] value goes to more than 15. Heck, if I just open few windows (kwrite, konsole and dolphin) I don't even have to move anything, to trigger long flushbuffer timings. Other elapsed[x] values only occasionally hit 1ms or more. Hope that helps :)

Oh... wait... damn... disregard my last comment. I messed something up :)

I'm an idiot ;) In the code there was one other qdebug throwing timings of waitSync(), and the timings I've described earlier are actually waitSync() execution times. Seems to me, that now I'm getting the same timings of ::flushBuffer as you get on your setup Thomas (less than 1ms, no matter if with or without mplayer). I'm not sure why these times were greater before, but in the meantime I've upgraded to kde4.6 rc2, and I also had an update of xorg server (I'm now on 1.9.3). Still, despite all those updates and normal flushbuffer timings I'm still getting this tearing problem (it's "properties" or "strength" did not changed even a bit).

at least we don't have that kind of problem.

two more nvidia specific related setting that could have impact:
a) OnDemandVBlankInterrupts (setting/getting via the cli does not work here, but there's a checkbox in the powersavings page of nvidia-settings)
b) 'Option      "TripleBuffer" "true"' in the Device section of /etc/X11/xorg.conf

the first might require a restart of kwin to take place, the second needs an X11 restart, but likely only applies to buffer swapping.

Have you tried 'c)' in comment #46, btw?

> Have you tried 'c)' in comment #46, btw?

Oh. yeah forgot to mentioned it. I've tried that - it doesn't help though.

I didn't have TripleBuffer setup in my xorg.conf, but setting it to "true" or "false" doesn't bring any improvements. As for OnDemandVBlankInterrupts - I don't see such option anywhere in my nvidia-settings panel, but "google says", it should also be set up through xorg.conf. I've tried that, and once again - doesn't matter if it's on or off - there is no visible effect (x server was restarted each time I made the changes in .conf file)

Hi

Sorry I have been so useless at testing, I was very busy and didn't know
how to install the KDE betas. I just tried out 4.6 RC2, and everything
is about the same as before, even with the options of #53 in xorg.conf.
I saw some "block tearing" when putting a kaffeine window over a flash
video.

It only happens on a secondary screen, but there is no way to put the
external monitor as primary.

Marius

(In reply to comment #55)
> It only happens on a secondary screen, but there is no way to put the
> external monitor as primary.

Err... that's (probably) normal - you must spend quite more money for a GPU that can apply different syncs to different devices =P

You can only sync to ONE display device, no idea why you cannot make your screen the primary one, but:

a) you could disable dynamic twinview in case you don't require it (probably you do?) - that should leave you with one display device, being the primary (option "DynamicTwinView" "false" --- "Device" section  in /etc/X11/xorg.conf

b) you can select to which device to sync to via an environment var "__GL_SYNC_DISPLAY_DEVICE" (see chapter 11C in /usr/share/doc/nvidia/README for the variable value)

Maybe I wrong, but AFAIK nVidia binary have own way to do sync with enabled compositing - GL_EXT_x11_sync_object. There is bugreport about it: https://bugs.kde.org/show_bug.cgi?id=280608

I'm testing kubuntu 12.10 alpha3, with an nvidia gtx680 and I get exactly the same tearing described above, when kwin vsync is enabled.
While dragging a window in the upper portion of the screen I can see a tear line that breaks the window in two. The lower portion of the window moves faster than the upper  one.
Both compiz and mutter have the same behavior with vsync, but both have workarounds that fix this issues.

In mutter, setting the env variable : CLUTTER_PAINT=disable-clipped-redraws:disable-culling, fix the problem.

In compiz, Workarounds, enable "Force full screen redraw (buffer swap) on repaint", also fix the problem.

Does kwin have a similar option to fix the tearing issues?

> While dragging a window in the upper portion of the screen I can see a tear
> line that breaks the window in two. The lower portion of the window moves
> faster than the upper  one.
> Both compiz and mutter have the same behavior with vsync, but both have
> workarounds that fix this issues.

Damn, and I thought it was some HDMI issue. I get the same thing - upper part of the screen tear windows apart (movie playback in XBMC and VLC seems to be not affected).

There's no such flag, but it *could* be done using an effect plugin (which just keeps the fullscreen mode active) - however that's not really a solution as it will increase bandwidth demands (and by this keep the driver in the performance mode)

It's also a bit strange that the waitSync extension would cause a reliable offset (seems as if it blocks until the retrace is *done* instead of until it starts) while glXSwapInterval does not (do you have the vsync feature in of the driver enabled? -> disable it and "kwin --replace&")

This should be trivial to fix in the driver (since it seems so obvious) but please also notice that wilth a 5200FX, a 7600GT and a GT520 i have *never* seen such behavior ever on four different displays (though i didn't test all combinations)

Has anybody with this issue ever contacted nvidia at nvnews?

>  kubuntu 12.10 alpha3
what kwin/KDE version is that?

> Has anybody with this issue ever contacted nvidia at nvnews?
More than one year ago (may 2011) they answer to my message about tearing "I have provided your input to our developers" and "unfortunately due to Engineering's large workload of bug fixes and adding features, there is currently no schedule" and "there is no blocker problem, only higher priority bug fixes and features that are delaying this work".

Thomas, I suggest you contact with nVidia from your side: http://nvidia.custhelp.com/app/ask
You may give them ticket refernce number 110510-000007 and ask when they plan to resolve problems with tearing, in 2013 or in 2014?

> what kwin/KDE version is that?
KDE 4.9 RC.

This issue happens with both vsync enabled or disabled in nvidia control panel. 
What´s strange is the fact that when I start kde, open a window and drag it doesn´t happen right away. It happens past a fews seconds.

I think this issue is major and affects a lot of users, and I don´t think this problem is restricted to nvidia, because I´ve seen reports of others cards having the same issues.

If mutter and compiz have workarounds for this issues, and this workarounds don´t require the card to be at full speed.

Look at this: http://lists.kde.org/?l=kwin&m=124976095808196&w=2, it happens with ati too.

(In reply to comment #62)
> This issue happens with both vsync enabled or disabled in nvidia control
> panel.
That switch only affect glXSwapBuffers what is hardly used unless you keep the compositor in fullscreen effect mode (the mentioned workarounds)

> What´s strange is the fact that when I start kde, open a window and drag it
> doesn´t happen right away. It happens past a fews seconds.
Past a few seconds of contrant dragging?

> If mutter and compiz have workarounds for this issues, and this workarounds
> don´t require the card to be at full speed.
Yes, they do.
What these workarounds do is to trigger full scene repaints all the time. Whether the driver thinks that's a reason to enter performance mode or not is up to the driver and possibly the GPU. It's either way raising costs and should be avoided.

> Look at this: http://lists.kde.org/?l=kwin&m=124976095808196&w=2,
Which is against 4.3.0 where the vsync code was effectively doing nothing and also describes an "overlapping" what is not tearing but a framefuffer corruption and i'll bet that it derived from trilinear filtering (mipmapping)

Also this tearing here happens in a constant section of the screen what means that the screen /is/ synced, but at the wrong time, what means that the sync either blocks to a wrong refresh rate or until the retrace is done instead until it starts.

Yes, constant window dragging. And it happens faster when I open two or more windows.

(In reply to comment #58)
> While dragging a window in the upper portion of the screen I can see a tear
> line that breaks the window in two. The lower portion of the window moves
> faster than the upper  one.

OK, I don't know what was the solution but after couple of upgrades lately I can't reproduce it anymore! :)

nvidia 304.37 and KDE 4.9

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/

https://git.reviewboard.kde.org/r/107198/