Bug 330794 - window movement lags with vsync and KWIN_USE_BUFFER_AGE=1 (and double buffering) on nvidia 334.x
Summary: window movement lags with vsync and KWIN_USE_BUFFER_AGE=1 (and double bufferi...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Unclassified
Component: compositing (show other bugs)
Version: 4.11.6
Platform: Archlinux Packages Linux
: NOR normal with 1 vote (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-05 10:54 UTC by Simonas
Modified: 2018-11-11 12:12 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
thomas.luebking: NVIDIA+


Attachments
Output of "qdbus org.kde.kwin /KWin supportInformation" (4.19 KB, text/plain)
2014-02-05 14:55 UTC, Michael Marley
Details
Qdbus output (5.38 KB, application/octet-stream)
2014-02-05 18:54 UTC, Simonas
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Simonas 2014-02-05 10:54:58 UTC
After the update i noticed that when you try to move window fast, it lags behind mouse cursor, and also the system becomes less responsible, the animations seems to have some miliseconds delay, it also seems the more i use the system the more laggy it becomes altough the lagging isn't very bad or critical, but it's still noticeable. This happens on latest Nvidia blob with having added these lines in /etc/profile (this is workaround, because vsync doesnt work without these lines added):
export __GL_YIELD="USLEEP"
if i disable vsync the problem goes away, or if i disable vsync and re enable it then vsync works fine and that problem goes away, until i logout, after new session it goes back and i have to repeat that procedure.

Reproducible: Always

Steps to Reproduce:
1.enable vsync
2.open few windows and try to move them
3.
Actual Results:  
the window becomes "lazy" and it lags after mouse cursor, altough there is no fps loss

Expected Results:  
it should follow mouse better like it did in 4.11.5
Comment 1 Thomas Lübking 2014-02-05 14:07:43 UTC
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
Comment 2 Michael Marley 2014-02-05 14:55:52 UTC
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.
Comment 3 Thomas Lübking 2014-02-05 18:27:38 UTC
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.
Comment 4 Michael Marley 2014-02-05 18:31:09 UTC
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.
Comment 5 Simonas 2014-02-05 18:54:53 UTC
Created attachment 85010 [details]
Qdbus output
Comment 6 Simonas 2014-02-05 19:02:22 UTC
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.
Comment 7 Thomas Lübking 2014-02-05 19:22:10 UTC
(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.
Comment 8 Thomas Lübking 2014-02-05 19:25:18 UTC
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)
Comment 9 Simonas 2014-02-05 19:49:53 UTC
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.
Comment 10 Simonas 2014-02-05 19:54:24 UTC
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
Comment 11 Thomas Lübking 2014-02-05 20:01:16 UTC
(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.
Comment 12 Simonas 2014-02-05 20:17:14 UTC
Well, then i start to see tearing, so I guess vsync is off.
Comment 13 Thomas Lübking 2014-02-05 20:24:24 UTC
despite export __GL_YIELD="USLEEP"  ?

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

?
Comment 14 Simonas 2014-02-05 20:34:58 UTC
Yes in all my tests I had  __GL_YIELD="USLEEP" enabled.
This is what i get:
glPreferBufferSwap: 99
Comment 15 Thomas Lübking 2014-02-05 20:50:41 UTC
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"?
Comment 16 Simonas 2014-02-05 21:04:32 UTC
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
Comment 17 Thomas Lübking 2014-02-05 21:08:41 UTC
(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 ;-)
Comment 18 Michael Marley 2014-02-05 21:10:02 UTC
Even if I put my vsync mode in full repaints, I still get the lag.
Comment 19 Thomas Lübking 2014-02-05 21:12:08 UTC
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)
Comment 20 Michael Marley 2014-02-05 21:18:15 UTC
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.
Comment 21 Simonas 2014-02-05 21:26:19 UTC
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?
Comment 22 Thomas Lübking 2014-02-05 21:32:07 UTC
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)
Comment 23 Michael Marley 2014-02-05 21:33:34 UTC
Have you been able to reproduce the issue then?
Comment 24 Thomas Lübking 2014-02-05 21:33:56 UTC
(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)
Comment 25 Michael Marley 2014-02-05 21:36:13 UTC
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.
Comment 26 Thomas Lübking 2014-02-05 22:14:01 UTC
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
....
Comment 27 Michael Marley 2014-02-05 22:52:20 UTC
So that will fix the lag?
Comment 28 Thomas Lübking 2014-02-05 22:56:09 UTC
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)
Comment 29 Simonas 2014-02-07 22:03:48 UTC
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
Comment 30 Thomas Lübking 2014-02-07 22:12:14 UTC
This does _only_ fix tearing when disabling buffer_age support and using frontbuffer coyping.
It has no other implications.
Comment 31 Simonas 2014-02-07 23:28:14 UTC
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
Comment 32 Michael Marley 2014-02-08 16:07:37 UTC
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."
Comment 33 Simonas 2014-02-08 17:04:51 UTC
@Michael
That looks interesting, but i'll wait until this version will hit repos
Comment 34 Thomas Lübking 2014-02-08 19:35:23 UTC
(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 =)
Comment 35 Michael Marley 2014-02-08 19:43:17 UTC
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
Comment 36 Michael Marley 2014-02-11 01:06:38 UTC
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.
Comment 37 Thomas Lübking 2014-02-11 02:20:15 UTC
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 =)
Comment 38 Michael Marley 2014-02-11 02:59:22 UTC
So should I go bug aaronp about it then?
Comment 39 Thomas Lübking 2014-02-11 03:01:09 UTC
I'd first try the latest driver (nevertheless), but there might be another way to trigger the "wrong buffer age report", sure.
Comment 40 Michael Marley 2014-02-11 03:02:03 UTC
I am already running 334.16, which I believe is the latest version available.
Comment 41 Thomas Lübking 2014-02-11 03:05:33 UTC
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)
Comment 42 Simonas 2014-02-16 13:50:49 UTC
Ok, so I installed nvidia 334.16 driver, but the problem still exists.
Comment 43 Simonas 2014-02-16 13:53:15 UTC
Here's my qdbus output btw:
http://paste.ubuntu.com/6943236
Comment 44 Thomas Lübking 2014-02-16 13:58:04 UTC
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
Comment 45 Simonas 2014-02-16 14:05:53 UTC
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.
Comment 46 Thomas Lübking 2014-02-16 14:26:33 UTC
(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?
Comment 47 Simonas 2014-02-16 14:39:21 UTC
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".
Comment 48 Michael Marley 2014-02-16 14:41:26 UTC
For me, the jelly still occurs even with triplebuffering turned on.  (I have had triplebuffering turned on the whole time.)
Comment 49 Simonas 2014-02-16 14:43:35 UTC
Btw, activating present windows or desktop grid effect will not fix the problem.
Comment 50 Thomas Lübking 2014-02-16 20:49:23 UTC
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.
Comment 51 Michael Marley 2014-02-16 20:58:16 UTC
I just tested my 8600m GT system and found that the lag is indeed gone if triple buffering is turned off.
Comment 52 Michael Marley 2014-02-16 20:58:48 UTC
Darn, I got that backwards.  On the 8600m GT, the lag is there with triple buffering and gone with double buffering.
Comment 53 Michael Marley 2014-02-16 21:01:24 UTC
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.
Comment 54 Simonas 2014-02-16 22:04:21 UTC
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.
Comment 55 Michael Marley 2014-02-16 22:35:43 UTC
Resolution changing has nothing to do with it for me; I am always running 1920x1080.
Comment 56 Thomas Lübking 2014-02-16 22:40:14 UTC
(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.
Comment 57 Michael Marley 2014-02-16 22:54:48 UTC
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.
Comment 58 Thomas Lübking 2014-02-16 23:29:34 UTC
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.
Comment 59 Thomas Lübking 2014-02-24 19:38:31 UTC
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
Comment 60 razrfalcon 2014-05-08 04:39:28 UTC
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.
Comment 61 Thomas Lübking 2014-05-08 11:17:35 UTC
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 &
Comment 62 razrfalcon 2014-05-08 12:16:48 UTC
% 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)
Comment 63 Thomas Lübking 2014-05-08 12:53:50 UTC
(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.
Comment 64 razrfalcon 2014-05-08 13:28:48 UTC
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.
Comment 65 Thomas Lübking 2014-05-08 13:48:40 UTC
#!/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)
Comment 66 razrfalcon 2014-05-08 13:58:40 UTC
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...
Comment 67 Thomas Lübking 2014-05-08 17:40:13 UTC
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
Comment 68 razrfalcon 2014-05-08 18:19:45 UTC
Option  "TripleBuffer"  
makes lag smaller, but still much worse than KWIN_USE_BUFFER_AGE=0
Comment 69 Thomas Lübking 2014-05-08 19:12:12 UTC
Thanks, ftr. i'm on 337.12 now - 334.x was only used during march on archlinux.
I'll have to downgrade now ;-)
Comment 70 Michael Marley 2014-05-08 19:13:39 UTC
The lag happens with 337.xx and with triple buffering here.
Comment 71 Andrew Crouthamel 2018-11-11 04:31:40 UTC
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!
Comment 72 Michael Marley 2018-11-11 12:12:46 UTC
This seems to have been fixed at some point, thanks!