Certain screen edge effects: Tiling a window, triggering Desktop Grid, and mouse-over on a window in Present Windows (before it zooms in a little), causes KWin to freeze for ~10s before resuming. Doing the same effect immediately after has no such stall, but doing it again a few minutes later will have the stall once more. Has only been observed with proprietary NVidia drivers. With both OpenGL 2.0 and 3.1 backends. Using KDE stable from kdesrc-build, and Qt 5.13 from git. Has been observed for a few months. Kwin produces no relevant console log output.
Can you post output of qdbus org.kde.KWin /KWin supportInformation ?
Created attachment 119649 [details] Kwin support info
Argh, support information for desktop grid doesn't include information I'm interested in. Anyways, if you uncheck "Show buttons to alter count of virtual desktops" in Desktop Grid settings and "Provide buttons to close the windows" in Present Windows settings, does KWin freeze when either one of those effects is active?
Yes disabling those two options for those effects fixes the issue for them.
Okay, it looks this is a duplicate of bug 406180.
Do you build KWin from source code?
Yes, I use kdesrc-build. I can also patch and build separately if you want to test something
To temporarily fix your issue you can revert 22a441e071515e9c630f3bdac743c678052f88be But given you can reproduce, it would be great if you can help investigate. We deadlock in #6 0x00007f7579c88750 in QOpenGLContext::swapBuffers(QSurface*) () at /usr/lib/libQt5Gui.so.5 After a QtQuick render. (DesktopGrid is using QtQuick for the buttons on the bottom) This happens when env var "__GL_MaxFramesAllowed" is set to 1 Which we do to work round a kwin timing expectation. Can you see if this we get the freeze with an animation in qmlscene?
I can't see that deadlock when breaking in gdb, but if I enable debug logging for qt.scenegraph.time.renderloop I get output like this: qt.scenegraph.renderloop: (RT) - rendering started qt.scenegraph.renderloop: (RT) - rendering done qt.scenegraph.renderloop: (RT) - wake Gui after initial expose qt.scenegraph.time.renderloop: Frame rendered with 'threaded' renderloop in 13148ms, sync=0, render=0, swap=13148 - (on render thread) So it waits 13 seconds apperently doing gl->swapBuffer()
> I can't see that deadlock when breaking in gdb It'll be blocking in the render thread. Thread 0 will be polling on that.
(In reply to David Edmundson from comment #10) > > I can't see that deadlock when breaking in gdb > > It'll be blocking in the render thread. Thread 0 will be polling on that. None of the threads were blocking, but I was running it in the ALT+2 terminal, so perhaps it unblocked whenever I changed screens. I couldn't run it in X11 as everything freezes when the issue happens.
Could you test kwin with https://phabricator.kde.org/P385
Is it still an issue in 5.26 or 5.27?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!