Bug 303397

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

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.

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?

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.

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

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

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?

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...

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 ;-)

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.

Created attachment 72576 [details]
kwin profile output (played with kwin about 15 secs)

(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.

With another decoration result is still same. Im attaching that file

Created attachment 72578 [details]
xorg log

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.

the cursir doesn't lag but your input does - XFlush clearly syncs to screen

What could this mean? Bad xorg configuration? This probably wont help, but im attaching xorg.conf just in case you see something wrong

Created attachment 72580 [details]
xorg.conf

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?)

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

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.

- 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?

you mean apply the profiling patch again? and also open scene_opengl_glx.cpp and add line, after applying profiling patch?

(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

Created attachment 72607 [details]
new output

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.

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 ;-)

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

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

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

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 :)