Bug 303397

Summary: KDE desktop effects are laggy when i uncheck Vsync option in system settings
Product: [Plasma] kwin Reporter: Simonas <obuolis1>
Component: generalAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED FIXED    
Severity: normal Flags: thomas.luebking: ReviewRequest+
Priority: NOR    
Version: 4.8.97   
Target Milestone: 4.9.0   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed In:
Attachments: use glFinish instead of glXwaitGL
profiling enabling patch
kwin profile output (played with kwin about 15 secs)
xorg log
xorg.conf
only glXswapInterval(1) if vsync is configured enabled
new output

Description Simonas 2012-07-12 08:11:33 UTC
When i uncheck option "Use Vsync" in system settings, my desktop becomes jittery like it has missing frames, and it actually does, because when i set MaxFPS in kwinrc to e.g. 500, then the desktop becomes smooth, but thats not solution because some effects become slow (like krunner slides smoothly but slowly). When i set fps to 60, then the desktop goes back to that jittery experience. Anyway when i have Use Vsync checked then its just fine. Im using latest nvidia 302.19 with latest xorg and all other stuff. 

Reproducible: Always

Steps to Reproduce:
1.see details
2.
3.
Actual Results:  
Desktop effects are laggy, altough fps plugin of kwin, shows 60 fps.

Expected Results:  
It should be as smooth as in pre 4.9 versions
Comment 1 Thomas Lübking 2012-07-12 12:12:25 UTC
Semi-confirmed. Setting the MaxFPS to eg. 40 makes it clearly stutter and drop frames.

The reason is glXWaitGL(), changing it to glFinish() used to "fix" this here (changing the frame painting from ~25ms to ~2, as if glXWaitGL performs a sync)

This might also be the cause or involved in bug #303202 - which unfortunately is not 100% reproducible (though it clearly happened more than one) here
Comment 2 Simonas 2012-07-15 13:23:03 UTC
I found that the older nvidia driver (295.59) and a newer beta (304.22) doesnt fix that problem. I also noticed lag even with vsync enabled, for example open 5 windows and try to minimize one of them, the minimize animation will be laggy. Those bugs are major imo, they make kde feel very laggy.
Comment 3 Thomas Lübking 2012-07-15 15:18:20 UTC
The nvidia driver syncs on glXWaitGL - no idea since when.
You'll get two syncs resulting in half framerate and for the unsynced variant it depends on when the sync occurs compared to the render timeout.

Can you compile a patch to confirm or deny whether replacing glXWaitGL() by glFinish() has an impact for you (as well - it pretty much seems the cause here)?

How's btw. your nvidia-settings configured, notably the nvidia vsync (it's now defaulted ON), the video texture adapter sync and flipping?
Comment 4 Simonas 2012-07-15 17:00:26 UTC
I have compiled and applied kwin patch few years ago, but i dont remember now. But you can post a patch ill try to apply and compile it, because i have some spare time today.
Comment 5 Simonas 2012-07-15 17:12:16 UTC
i found on kde forum instructions on compiling it: 
git clone git://anongit.kde.org/kde-workspace.git
cd kde-workspace
git checkout master
[download the patch]
patch -p1 < patch.diff
(notice that it may be p2, p3 or whatever, the patch should just apply without asking for what file to patch, than it's the wrong offset)
mkdir build; cd build
cmake -DCMAKE_INSTALL_PREFIX=$PREFIX ..
XOR
cmake -DCMAKE_INSTALL_PREFIX=$PREFIX -DCMAKE_BUILD_TYPE=Release ..
(builds & strips and stuff)
ccmake ..
[adjust build configuration, mainly you can disable everything BUILD_* but BUILD_kwin]
make && sudo make install
[wait, enter password for sudo]
kwin --replace &
-> profit
if its that simple its not gonna take long
Comment 6 Simonas 2012-07-15 17:19:46 UTC
about nvidia-settings, i have disabled opengl syncing for performance reasons, x sync is on, but i have tried to disable it too but it doesnt affect kde performance. I probably have played with all the options, neither of them fixed the performance
Comment 7 Thomas Lübking 2012-07-15 17:45:02 UTC
Created attachment 72537 [details]
use glFinish instead of glXwaitGL

Patch attached, yes - compiling should be that easy ;-)

Notice that this is quite a heisenbug here, ie. sometimes the frames seem just to match the assumed glXWaitGL sync and sometimes not. I could however not reproduce the lags with glFinish and according to some mail i can't find right now, glXWaitGL is pointless anyway because of the redirection.

You're aware that you have to restart "kwin --replace&" after altering nvidia.settings?
Comment 8 Simonas 2012-07-15 20:13:58 UTC
well i applied the patch, it outputed, that diff file has been patched fine, i compiled and installed everything fine, but the problem still isnt fixed :(
now im not sure whats wrong...
Comment 9 Thomas Lübking 2012-07-16 20:06:14 UTC
Created attachment 72566 [details]
profiling enabling patch

First of all we need to figure what causes the frame drop

1) is the desktop laggy all the time (when just dragging around a window) or when invoking certain effects such as "present windows"?
For this purpose also please disable blurring and set the scale method to "smooth"

2) we got to figure which function blocks for you
Attached is a patch that applies to the vanilla code. It will make kwin *very* talky while the compositor is on and esp. on screen update why you must NEVER run it as "kwin --replace" but use 
    kwin --replace > ~/kwin.profile 2>&1 &
instead (it will launch kwin into the background and most important redirect all output to ~/kwin.profile)

So apply the patch and make kwin lag - then we'll have a look where we loose the time.
(since kwin will bloat your xsession.errors you better revert the patch for everyday use - is just as applying it, but use "patch -R -p0 < patch.file"

3) we got to figure "why"
... after  we figured "where"

Now that you've compiling sources that should be doable ;-)
Comment 10 Simonas 2012-07-17 08:22:55 UTC
I am currently compiling the code.
1. Not all the desktop, for example sliding animation (when i click to open kmenu) is smooth, window movement is laggy for first second but then its smooth, while minimize animation effect is jittery, window maximize/restore has few seconds lag, when i open on logout dialog that fading effect is laggy and even makes my mouse cursor lag, the same is the splash screen to desktop transistion (on startup), it makes my mouse cursor lag when moving. So the overall experience is still laggy.
Talking about disabling blur and scale method to smooth, i already got them set. Makes no change at all. I will attach the kwin.profile as soon as i will be done.
Comment 11 Simonas 2012-07-17 08:29:46 UTC
Created attachment 72576 [details]
kwin profile output (played with kwin about 15 secs)
Comment 12 Thomas Lübking 2012-07-17 08:30:50 UTC
(In reply to comment #10)
> I am currently compiling the code.
> 1. Not all the desktop, for example sliding animation (when i click to open
> kmenu) is smooth, window movement is laggy for first second but then its
> smooth, while minimize animation effect is jittery, window maximize/restore
> has few seconds lag, when i open on logout dialog that fading effect is
> laggy and even makes my mouse cursor lag, the same is the splash screen to
> desktop transistion (on startup), it makes my mouse cursor lag when moving.
> So the overall experience is still laggy.

Can you please try another decoration, say "laptop"?
Also the cursor should NEVER lag, it's supposed to be a server feature and written into the FB directly by the driver -> "grep -i silk /var/log/Xorg.0.log" - possibly attach that file.
Comment 13 Simonas 2012-07-17 08:51:35 UTC
With another decoration result is still same. Im attaching that file
Comment 14 Simonas 2012-07-17 08:53:04 UTC
Created attachment 72578 [details]
xorg log
Comment 15 Simonas 2012-07-17 08:56:03 UTC
hmm i just found out that the mouse cursor lag happens on every laggy effect, so when i minimize window during that animation my mouse also lags. Or if i press ctrl + f12 widget dashboard fading animation is laggy and also makes my mouse cursor movement laggy.
Comment 16 Thomas Lübking 2012-07-17 09:18:43 UTC
the cursir doesn't lag but your input does - XFlush clearly syncs to screen
Comment 17 Simonas 2012-07-17 09:22:45 UTC
What could this mean? Bad xorg configuration? This probably wont help, but im attaching xorg.conf just in case you see something wrong
Comment 18 Simonas 2012-07-17 09:23:18 UTC
Created attachment 72580 [details]
xorg.conf
Comment 19 Thomas Lübking 2012-07-17 12:30:50 UTC
Created attachment 72584 [details]
only glXswapInterval(1) if vsync is configured enabled

XFlush likely doesn't block (the profile_t int ins't updated in the patch, so you got the time for buffer flushing twice)

There's probably however a real bug because for fullscreen usage glXSwapInterval is set to 1 for buffer flushing regardless of anything.

This was possibly exposed by a change in the intel driver, for i get 2 fames sync on a glXSwapInterval(1) in a completely different application as well (and -apparently- three for "2")

Try attached patch, has only impact on whenever a fullscreen effect is in action and vsync is off (and the minimize effect pot. is?)
Comment 20 Simonas 2012-07-17 13:44:20 UTC
So i applied the patch, and desktop became much smoother. Altough still not as completely smooth as it was on 4.8. I still see a small fps loss. Also the mouse stopped lagging during animations
Comment 21 Simonas 2012-07-17 14:16:26 UTC
Yes the frames are still missing and they are not 60 fps, because when i double the fps when setting MaxFPS=120 desktop becomes totally smooth. Some of other things still lag a bit, like when i grab the window and try to move in first second it lags but then goes smooth, that wasnt in 4.8. Anyway the major lag side is gone, now only need to figure out those missing fps.
Comment 22 Thomas Lübking 2012-07-17 18:37:33 UTC
- What does the fps counter say on en- and disabled vsync
- can you re-apply the patch, fix it (in scene_opengl_glx.cpp after XFlush(display()); add a line "profile_t = profiler.elapsed();" and create another profile on laggy action (which one? still fullscreen?)
- can can try again with a 295.xxx driver
- nothing, including the patch, explains why the mouse would "lag" - either the server blocks or the pointer is not in HW (but the Xorg log says it is) -> do you have the zoom effect enabled and can you try to deactivate it?
Comment 23 Simonas 2012-07-18 10:58:18 UTC
you mean apply the profiling patch again? and also open scene_opengl_glx.cpp and add line, after applying profiling patch?
Comment 24 Thomas Lübking 2012-07-18 11:53:40 UTC
(In reply to comment #23)
> you mean apply the profiling patch again? and also open scene_opengl_glx.cpp
> and add line, after applying profiling patch?

yes - if we still leak (sync?) frames, we got to know where and why.
I understood that despite setting MaxFPS to 60 you did not end up with 60FPS w/o vsync but with 120FPS you did? -> there's somewhere an unwanted and unpredicted sync to screen
Comment 25 Simonas 2012-07-18 12:26:34 UTC
Created attachment 72607 [details]
new output
Comment 26 Simonas 2012-07-18 12:34:52 UTC
fps counter shows 60 fps, no matter if vsync is enabled or disabled. i just noticed a weird thing, when i have vsync disabled and enable fps counter, the desktop becomes completely smooth, when i disable it, then it goes back less smooth. And well this frame loss isnt that big, for some reason i did git clone today (downloaded latest kwin branch) and it seems that with this branch it became more smooth, the animation frame loss became even smaller, altough still exists. Also i have applied all three your patches, profiling enabling patch, glxswapinterval and use glfinish. Altough i have applied those three yesterday too.
Comment 27 Thomas Lübking 2012-07-20 19:04:06 UTC
Thanks alot for your efforts.

It's "normal" that sync'd painting appears more "smooth" or "steady" than unsync'd because the content does not tear or "break" vertically - causing the impression that a part of the window lags behind.

You're loosing all time in the paintScreen code which should not be affected by syncing at all.

If you want to be extra-nice, i'd like to see a profile with glXWaitGL NOT replaced by glFinish() to ensure the driver does not wait for anything extra here.

You "may" also provide a profile with enabled sync to check whether there's significant difference in the paintScreen() time (in which case we'd have to profile that in detail as well ;-)
Comment 28 Thomas Lübking 2012-07-20 20:06:59 UTC
https://git.reviewboard.kde.org/r/105632/
Comment 29 Thomas Lübking 2012-07-21 18:17:38 UTC
Git commit 91448e1e74e9b3484148d6afe626ef6a7e7dc350 by Thomas Lübking.
Committed on 18/07/2012 at 01:50.
Pushed by luebking into branch 'KDE/4.9'.

fix conditional glXSwapInterval usage

and cleanup profiling relics

REVIEW: 105632
(cherry picked from commit 0babc455aea4f5099a4f829668160bda3ef68a28)

M  +1    -2    kwin/composite.cpp
M  +7    -6    kwin/scene_opengl_glx.cpp

http://commits.kde.org/kde-workspace/91448e1e74e9b3484148d6afe626ef6a7e7dc350
Comment 30 Thomas Lübking 2012-07-21 18:34:32 UTC
Git commit 0babc455aea4f5099a4f829668160bda3ef68a28 by Thomas Lübking.
Committed on 18/07/2012 at 01:50.
Pushed by luebking into branch 'master'.

fix conditional glXSwapInterval usage

and cleanup profiling relics

REVIEW: 105632

M  +1    -2    kwin/composite.cpp
M  +7    -6    kwin/scene_opengl_glx.cpp

http://commits.kde.org/kde-workspace/0babc455aea4f5099a4f829668160bda3ef68a28
Comment 31 Simonas 2012-07-23 17:36:23 UTC
Thank you very much for fixing this bug. I would like to test like you said more stuff, but i will be very busy for some time now, and i wont have time to do this. Anyway when i will have some spare time, ill test more things :)