also see bug #329821

copied from there:
--
I just discovered a reliable way to reproduce the lag at any time.  If I run an application that is playing a video or doing any kind of continuous animation, it makes all window dragging lag in exactly the same way I described with the circular dragging earlier.
--
My monitor does run at 60Hz and I do have KWIN_TRIPLE_BUFFER=1 set, so that sounds right.

And moving through jelly is a good description.  It is still smooth, but just is smooth farther behind the mouse cursor than it was before buffer_age was introduced.
------
I guess it feels like moving through jelly, the window follows the mouse - it does not hang and then jump to the mouse position?

Dev note:
This would mean we load the swapbuffer with too many swaps what can basically have two reasons:

1. misdetection/overridden refreshrate/MaxFPS
2. triplebuffer misdetection (assumed to be NOT available, while it indeed is)

According to the present debug output, the refreshrate is detected as 60Hz (what is supported by the nvidia-settings query) - so it had to be 3buf detection, just that comment #25 explicitly states that this occurred WITH KWIN_TRIPLE_BUFFER=1 ...

So there must be a third reason to overcommit frames (could be broken paint time calculation)



> export __GL_YIELD="USLEEP"
You've no triple buffering enabled?
Please attach the output of
   qdbus org.kde.kwin /KWin supportInformation

Created attachment 85005 [details]
Output of "qdbus org.kde.kwin /KWin supportInformation"

Here is my output from "qdbus org.kde.kwin /KWin supportInformation".

I am still running the same configuration as I was for the last bug (triple buffering on, KWIN_TRIPLE_BUFFER=1, and vsync set to auto).

One more possibly-relevant bit: If I have a 30fps video file playing in an mplayer window and put it directly behind a Firefox window, when I start scrolling in Firefox, the section of the Firefox window that covers up the mplayer window updates before the rest of the Firefox window, causing a rectangular box of "tearing".  This "tearing" goes away after one or two frames of animation, but it is definitely there.

thanks, but i mostly wonder about simonas' setup - if it's not triplebuffering, frame overcommit should be a red herring.

the "tearing" would suggest that the occlusion check is broken (for buffer_age only?) - unless the FF window is translucent or at least argb.

It doesn't look like he is using triple buffering (he said that vsync would not work without __GL_YIELD="usleep".

I can reproduce the "tearing" with applications other than Firefox too, so I guess I will file another bug about that.

Created attachment 85010 [details]
Qdbus output

No, i'm not using triple buffering, but if i do now:
export KWIN_TRIPLE_BUFFER=1
kwin --replace &
Then the window lagging behind cursor is gone mostly, it still feels a little bit lagging behind mouse, but the difference is that window no longer jitters when moved, because there was very little jittering in 4.11.5 and earlier when i moved windows. But again that lagging is so little that its really hard to even notice that, and if we count that windows no longer have very little jitter like they used to, i guess its fine. 
And for me that window lagging behind cursor happens on every window for me, be it firefox, terminal or dolphin.

(In reply to comment #6)
> No, i'm not using triple buffering, but if i do now:
> export KWIN_TRIPLE_BUFFER=1

it's not that simple.
What does
   grep -i triple /var/log/Xorg.0.log
say?

Then

unset KWIN_TRIPLE_BUFFER
kwin --replace &
# wait some time while the screen is updated
qdbus org.kde.kwin /KWin supportInformation

Those informations are crucial so that we're not blindly guessing around on causes here.

Ok, sorry - this:
> Painting blocks for vertical retrace:  yes
Means you had not exported that setting, but triple buffering is detected as unavailable.

If it was indeed be enabled (Xorg.0.log grep) but misdetected, that would explain the lagging (since overcommit can be expected)

Yes, I made the attached file when i didn't have triple buffering set with that command. 
For some reason when i do grep -i triple /var/log/Xorg.0.log, terminal outputs me nothing, but here is a full file:
http://paste.kde.org/p0649650c
Another interesting thing i noticed is that when i boot to my kde desktop and quickly open any window, the window movement is good for like first 5-7 seconds and after that time this problem occurs.

And here is output of qdbus when i have triple buffering set with that command (if relevant):
http://paste.kde.org/p05e840b0
and Xorg.0.log file with triple buffering set:
http://paste.kde.org/p67ea1081

(In reply to comment #9)
> For some reason when i do grep -i triple /var/log/Xorg.0.log, terminal
> outputs me nothing, but here is a full file:

The reason is that triple buffering is actually not enabled (and that being correctly detected)
In 4.11.5, the detection was broken (bug #329821) and ..

> Another interesting thing i noticed is that when i boot to my kde desktop
> and quickly open any window, the window movement is good for like first 5-7
> seconds and after that time this problem occurs.

... during the detection phase, triple buffering is assumed to be available.

Now, this is really interesting, since w/o triple buffering, glSwap will block (and wait for the retrace - the reason why gl yielding needs to be usleep; otherwise it's expensive) what means, there's no chance for an overcommit.

w/o actual triple buffering, exporting KWIN_TRIPLE_BUFFER is *clearly* wrong (it'll lead to jitter for missing retraces)

Try instead:
-------------------
unset KWIN_TRIPLE_BUFFER
export KWIN_USE_BUFFER_AGE=0
kwin --replace &

and report about the result.

Well, then i start to see tearing, so I guess vsync is off.

despite export __GL_YIELD="USLEEP"  ?

Is this then:
    qdbus org.kde.kwin /KWin supportInformation | grep glPreferBufferSwap
> glPreferBufferSwap: 0

?

Yes in all my tests I had  __GL_YIELD="USLEEP" enabled.
This is what i get:
glPreferBufferSwap: 99

unless this is kwin_gles, that indicates
a) swapInterval is "1"
b) every frame is swapped
-> no option for actual tearing (unless you had disabled flipping in nvidia-settings)

What happens when setting the tearing prevention to "full repaints"?

with full scene repaints set vsync starts to work fine, and i get no issue with window lagging behind mouse cursor, in other words it works exactly like it did with 4.11.5. Just in case that's the output now:
glPreferBufferSwap: 112

(In reply to comment #16)
> in other words it works exactly like it did with 4.11.5.
FTR: no, it doesn't - in 4.11.5 it was more like as if you had KWIN_TRIPLE_BUFFER=1 exported.

This however implies the frontbuffer copying path had been broken, so to be absolutely sure: it's NOT kwin_gles, is it? (yes: nvidia meanwhile supports GLES, in case you wonder ;-)

Even if I put my vsync mode in full repaints, I still get the lag.

Have "export KWIN_USE_BUFFER_AGE=0" ? (And please keep tearing prevention automatic or "copy frontbuffer" at first - to confirm or deny that the path is broken, thanks)

With buffer age disabled, I get a small bit of lag (not nearly as bad as with buffer age) when using full scene repaints and no lag (but tearing) in re-use screen content.

well i meant that the performance is as good (or even better) as in 4.11.5. 
I'm using default archlinux kde packages and as far as i know they aren't using GLES, but i might be wrong, is there a way to check that?

On arch, you'd have to do some extra in order to get kwin_gles running on nvidia (they don't ship the nvidia GLES/EGL libs atm., pakage conflict, I assume) - so this is kwin/glx.

I'm compiling a debug output enabled kwin to see whether and what's wrong here (FB copying)

Have you been able to reproduce the issue then?

(In reply to comment #20)
> With buffer age disabled, I get a small bit of lag
One frame lag is part of triple buffering (and the cursor is painted in HW directly into the framebuffer, thus not affected by "triple buffering", compositing or anything else)

I know.  The small bit of lag without buffer_age doesn't really bother me.

By the way, I have noticed that on Microsoft® Windows®, they seem to turn off the hardware cursor and paint the cursor image in the same way as the window.

Copying Frontbuffer broke at some point.
Replace: scene_opengl.cpp

qint64 SceneOpenGL::paint(QRegion damage, ToplevelList toplevels)
{
....
        validRegion != displayRegion) {
        glReadBuffer(GL_FRONT);
        copyPixels(displayRegion - validRegion);
        glReadBuffer(GL_BACK);
-        damage = displayRegion;
+        validRegion = displayRegion;
    }
#endif
....

So that will fix the lag?

No, only the frontbuffer copying path (which is not used if gl_buffer_age is supported, which is apparently the "lagging" path)
Frontbuffer copying is (on nvidia, do not use it on MESA ever) however more performant than full scene repaints (notably with blurring enabled)

I've manually replaced damage = displayRegion; line with validRegion = displayRegion;, compiled and installed everything, but the same problem still exists, that's my qdbus output now:
http://pastebin.kde.org/pc08ef922

This does _only_ fix tearing when disabling buffer_age support and using frontbuffer coyping.
It has no other implications.

Ah yes, if i set export KWIN_USE_BUFFER_AGE=0, then vsync works fine when i have it set to automatic. So yeah, it works then

Version 334.16 of the NVIDIA blob was just recently released, and I noticed something interesting and potentially relevant in the changelog:

"Fixed a bug in the GLX_EXT_buffer_age extension where incorrect ages would be returned unless triple buffering was enabled."

@Michael
That looks interesting, but i'll wait until this version will hit repos

(In reply to comment #32)
> "Fixed a bug in the GLX_EXT_buffer_age extension where incorrect ages would
> be returned unless triple buffering was enabled."
But you've triple buffering enabled, don't you?

Do you think the lag is more than two frames?
(hint: if you can record it, that's easy to figure =)

Here is a crappy recording of the lag.  Sorry about the video quality.  I need to buy a better potato.  I am pretty sure the lag is more than 2 frames, since I was using triple buffering without the lag before buffer_age was introduced.

http://youtu.be/LgniWcZY190

Curiously, I cannot seem to reproduce the lag on a system with an older NVIDIA GPU (GeForce 8600m GT), but I can reproduce it on one system with a Quadro NVS 5400m and another with a GeForce GTX650.

I don't get it on a GT520 - points a driver issue, but Simonas is on a GeForce 9500 (though he could simply suffer from the bug addressed in the latest driver, as he's triple buffering disabled)

About the video - i rather meant a screencast (since this has also the issue to sync cam and screen)
However, the lag does not seem too many frames (the window is indeed quite behind the cursor, but when you stop the movement they align very fast)
Frame counting on a "cinerip" is however pointless =)

So should I go bug aaronp about it then?

I'd first try the latest driver (nevertheless), but there might be another way to trigger the "wrong buffer age report", sure.

I am already running 334.16, which I believe is the latest version available.

Then you would indeed have to ask (though report from Simonas could be very helpful here, since his GPU is older than mine and if 334.16 fixes it for him, that would stress buffer age report relevance)

Ok, so I installed nvidia 334.16 driver, but the problem still exists.

Here's my qdbus output btw:
http://paste.ubuntu.com/6943236

Can you please check whether this also occurs for your with triple buffering enabled?

/etc/X11/xorg.conf.d/20-nvidia.conf 
Section "Device"
        Identifier "Default nvidia Device"
        Driver "nvidia"
        Option "NoLogo" "True" # no advertising ;-)
        Option "CoolBits" "1" # nice to have
        Option "TripleBuffer" "True" # that's the important one
EndSection

The problem still occurs, thats the qdbus output now:
http://paste.ubuntu.com/6943297
I found another workaround, i open e.g. some game (like scummvm) go to full screen with alt + enter and then go back, and this jelly problem is gone until i restart kde.

(In reply to comment #45)
> The problem still occurs, thats the qdbus output now:

> Painting blocks for vertical retrace:  yes
This does not suggest that TripleBuffering is enabled (you need to restart X11/KDM; "grep -i triple /var/log/Xorg.0.log" to ensure it's enabled)

For triple buffering misdetection, frame overcommit (with at least one frame) can be expected (and will lead to jelly)

> I found another workaround, i open e.g. some game (like scummvm) go to full
> screen with alt + enter and then go back, and this jelly problem is gone
> until i restart kde.

This is however rather interesting.
> unredirectFullscreen: true
Does it also work when not "suspend compositing for fullscreen windows" in "kcmshell4 kwincompositing", 3rd tab?
I assume simply triggering a fullscreen update (eg. activating the present windows or desktop grid effect) will not do?

For some reason it ignored what i have set in /etc/X11/xorg.conf.d/20-nvidia.conf, but setting it in /etc/X11/xorg.conf works, and now as triple buffering is enabled the problem no longer occurs. 
Yes, this workaround works even when i have unchecked "suspend compositing for fullscreen windows".

For me, the jelly still occurs even with triplebuffering turned on.  (I have had triplebuffering turned on the whole time.)

Btw, activating present windows or desktop grid effect will not fix the problem.

We've apparently two effects here.
One affecting Fermi (only) even on triple buffering and
Another one afffecting also "older" chips (at least GF9xxx) on double buffering only, that is affected by "starting a fullscreen game"

Both are related to invocation of GL_BUFFER_AGE.

@Simonas,
does the trick also work with NON OpenGL fullscreen "games"/applications?
Eg. playing a video on xv?
Does eg. a fullscreen xcreensaver ahck have impact depending on whether its GL or not?

I'll deactivate TB here and see what happens on next login.

I just tested my 8600m GT system and found that the lag is indeed gone if triple buffering is turned off.

Darn, I got that backwards.  On the 8600m GT, the lag is there with triple buffering and gone with double buffering.

Sorry, I am a complete idiot.  Disregard all my previous posts about the 8600m GT.

On the 8600m GT, if I have triple buffering turned on, I get no lag.

On the 8600m GT, if I have triple buffering turned off, I get lag.

Sorry for the spam.

Apparently this seems to happen only with resolution changers no matter if it's opengl app or not, but i'll investigate further to be 100% sure.

Resolution changing has nothing to do with it for me; I am always running 1920x1080.

(In reply to comment #55)
> Resolution changing has nothing to do with it for me; I am always running
> 1920x1080.

The idea is that the resolution change (by a fullscreen game at least) will "fix" it on double buffering.

I just tested changing resolutions while using double buffering on the NVS 5400m and it has no effect (still lags), so this must be one of the GPU-specific things.

Ok, sth.'s fishy here.

I'm still on 331.38 and with double buffering i see two things happen:

1.  On fast window movement, there's a "ghost" frame, like the last frame blended into the current (but may be a lazy eye effect and it's because of frame swapping)
I assume this to be the known nvidia bug and it happens regardless of the below.

2. When (re)starting kwin, it's initially snappy, then the swapping is detected to be blocking, enters the blocking path and starts to lag.
After suspending and restarting the compositor (could be autosuspending rule for Simonas?) the availability of triple buffering is assumed and the lagging stops.
-> That's probably a bug in kwin since iirc, the detection is not supposed to be run more than once, but the availability should certainly not be reset either.

Disabling BUFFER_AGE still correctly detects triple buffering to be NOT available, but there's no whatsoever lag.

I'll wait for 334.16 hitting arch repos and then measure frame comit & swap times on double buffering.

Git commit b00cc9cda191795ceae874526c7bd57b2a832982 by Thomas Lübking.
Committed on 05/02/2014 at 23:16.
Pushed by luebking into branch 'KDE/4.11'.

fix frontbuffer copying swap preference

REVIEW: 115523
Related: bug 322060

M  +1    -1    kwin/scene_opengl.cpp

http://commits.kde.org/kde-workspace/b00cc9cda191795ceae874526c7bd57b2a832982

Hello.
I just updated from KDE 4.11.5 to 4.12.5 (kwin 4.11.9) and faced this bug.
I use only __GL_YIELD="USLEEP" to make VSync work (no KWIN_TRIPLE_BUFFER and other).
Without VSync all works good and fast. With VSync I have lag while windows moving. Usually it small 2-3pix, some times even 10-15pix between start mouse postion and current. Also all animations looks lazy. Especially window resizing.

NVidia GTX650Ti, driver 334.21. Gentoo.

what's the output of:
   grep -i triple /var/log/Xorg.0.log
   qdbus org.kde.kwin /KWin supportInformation | grep -i block

what happens on:
   export KWIN_USE_BUFFER_AGE=0
   kwin --replace &

% grep -i triple /var/log/Xorg.0.log
return nothing

% qdbus org.kde.kwin /KWin supportInformation | grep -i block
Painting blocks for vertical retrace:  yes

After disabling and reenabling VSync answer is "no". And everything work normal again. Sort of.

So basically I need to reenable vsync manually after each reboot. Without it I have huge lags and slow animations.

KWIN_USE_BUFFER_AGE do not change anything or I do not see the result.
But I have warning:
kwin: unable to claim manager selection, another wm running? (try using --replace)

(In reply to comment #62)
> % grep -i triple /var/log/Xorg.0.log
> return nothing
> 
> % qdbus org.kde.kwin /KWin supportInformation | grep -i block
> Painting blocks for vertical retrace:  yes

That should be correct.

> After disabling and reenabling VSync answer is "no". And everything work
> normal again. Sort of.

That is a (known) bug - it's not correctly redetectd.

> So basically I need to reenable vsync manually after each reboot. Without it
> I have huge lags and slow animations.

This sounds as if triple buffering was enabled (though not configured), misdetected (thus "Painting blocks for vertical retrace:  yes") and therefore frames would be overcomitted, what would be *extremely* strange (bug in driver and kwin driver state detection)

-> Please check the impact of "export KWIN_USE_BUFFER_AGE=0" first.

> kwin: unable to claim manager selection, another wm running? (try using
> --replace)
You apparently did not pass the parameter then? ("kwin --replace &")
W/o there's no new process and KWIN_USE_BUFFER_AGE is not taken into account.

KWIN_USE_BUFFER_AGE=0 fix the lag.
Thanks.


Warning was shown because I start kwin via bash script:
#!/bin/bash
__GL_YIELD=USLEEP /usr/bin/kwin

Because adding __GL_YIELD to /etc/profile does not work for me.
And so I have actualy 2 kwin process, actual kwin, and script with same name.

#!/bin/bash
__GL_YIELD=USLEEP /usr/bin/kwin "$@" &

there's been a bug in the nvidia driver about reporting the wrong buffer age unless triple buffering, but afaics that should have been fixed (and i can at hand not imagine how that would lead to laggy dragging, rather flicker)

You could try whether activating triple buffering "fixes" the issue as well (w/ KWIN_USE_BUFFER_AGE=1)

KWIN_USE_BUFFER_AGE=1
does not fix it, all works like without it 

Also at startup all works good. Bug start to "work" after 10-20 second after system start. Like they need time to start up...

It's the default value.
What I wanted you to test is WITH enabled buffer_age support and WITH enabled triple buffering:

/etc/X11/xorg.conf.d/20-nvidia.conf 

Section "Device"
    Identifier "Default nvidia Device"
    Driver      "nvidia"
    Option      "NoLogo"                                "True"
        Option  "CoolBits"                              "1"
        Option  "TripleBuffer"                  "True" # <- that's the relevant line
EndSection

Option  "TripleBuffer"  
makes lag smaller, but still much worse than KWIN_USE_BUFFER_AGE=0

Thanks, ftr. i'm on 337.12 now - 334.x was only used during march on archlinux.
I'll have to downgrade now ;-)

The lag happens with 337.xx and with triple buffering here.

Dear Bug Submitter,

This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond.

Thank you for helping us make KDE software even better for everyone!

This seems to have been fixed at some point, thanks!