Bug 372576 - Present Windows lags when closing window
Summary: Present Windows lags when closing window
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: effects-present-windows (show other bugs)
Version: 5.13.3
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 375504 390088 405178 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-11-17 09:45 UTC by Fabian Vogt
Modified: 2019-06-28 10:01 UTC (History)
21 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Possible workaround (1.84 KB, patch)
2016-11-17 11:41 UTC, Martin Flöser
Details
Other possible workaround (2.36 KB, patch)
2017-03-11 17:08 UTC, Fabian Vogt
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Fabian Vogt 2016-11-17 09:45:08 UTC
When using the close button provided by the effect, the frame rate drops to 0 fps for multiple seconds.
It seems to only affect X11 platforms.

Likely related, but not quite the same: bug 371731
Comment 1 Martin Flöser 2016-11-17 10:28:29 UTC
I tried to break and got:

Thread 1 (Thread 0x7f5cae991940 (LWP 13565)):
#0  0x00007f5cae485b5d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f5cad5cbc62 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2  0x00007f5cad5cd9a9 in xcb_wait_for_special_event () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x00007f5ca502b6b7 in ?? () from /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
#4  0x00007f5ca502c460 in ?? () from /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
#5  0x00007f5c81899f4b in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#6  0x00007f5c8189a2a1 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#7  0x00007f5c8188b8d0 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#8  0x00007f5ca7785e8a in QSGBatchRenderer::Renderer::renderBatches() () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#9  0x00007f5ca778b734 in QSGBatchRenderer::Renderer::render() () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#10 0x00007f5ca779738f in QSGRenderer::renderScene(QSGBindable const&) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#11 0x00007f5ca7797a4b in QSGRenderer::renderScene(unsigned int) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#12 0x00007f5ca77a75ee in QSGRenderContext::renderNextFrame(QSGRenderer*, unsigned int) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#13 0x00007f5ca77f0ca9 in QQuickWindowPrivate::renderSceneGraph(QSize const&) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#14 0x00007f5ca77be345 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#15 0x00007f5ca77fb263 in QQuickWindow::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#16 0x00007f5cacbde89c in QApplicationPrivate::notify_helper (this=<optimized out>, receiver=0x289ae40, e=0x7ffe95643490) at kernel/qapplication.cpp:3799
#17 0x00007f5cacbe6296 in QApplication::notify (this=0x7ffe95643a90, receiver=0x289ae40, e=0x7ffe95643490) at kernel/qapplication.cpp:3556
#18 0x00007f5cac2f2cf8 in QCoreApplication::notifyInternal2 (receiver=receiver@entry=0x289ae40, event=event@entry=0x7ffe95643490) at kernel/qcoreapplication.cpp:988
#19 0x00007f5cac64fd6e in QCoreApplication::sendEvent (event=0x7ffe95643490, receiver=<optimized out>) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:231
#20 QWindowPrivate::deliverUpdateRequest (this=this@entry=0x2115d60) at kernel/qwindow.cpp:2171
#21 0x00007f5cac6502b9 in QWindow::event (this=0x289ae40, ev=<optimized out>) at kernel/qwindow.cpp:2142
#22 0x00007f5ca77fb285 in QQuickWindow::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#23 0x00007f5cacbde89c in QApplicationPrivate::notify_helper (this=<optimized out>, receiver=0x289ae40, e=0x7ffe956437c0) at kernel/qapplication.cpp:3799
#24 0x00007f5cacbe6296 in QApplication::notify (this=0x7ffe95643a90, receiver=0x289ae40, e=0x7ffe956437c0) at kernel/qapplication.cpp:3556
#25 0x00007f5cac2f2cf8 in QCoreApplication::notifyInternal2 (receiver=0x289ae40, event=event@entry=0x7ffe956437c0) at kernel/qcoreapplication.cpp:988
#26 0x00007f5cac34516e in QCoreApplication::sendEvent (event=0x7ffe956437c0, receiver=<optimized out>) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:231
---Type <return> to continue, or q <return> to quit---
#27 QTimerInfoList::activateTimers (this=this@entry=0x1e91f30) at kernel/qtimerinfo_unix.cpp:644
#28 0x00007f5cac341f6c in QEventDispatcherUNIXPrivate::activateTimers (this=this@entry=0x1e91e90) at kernel/qeventdispatcher_unix.cpp:249
#29 0x00007f5cac343148 in QEventDispatcherUNIX::processEvents (this=<optimized out>, flags=..., flags@entry=...) at kernel/qeventdispatcher_unix.cpp:509
#30 0x00007f5c97d0f86d in QUnixEventDispatcherQPA::processEvents (this=<optimized out>, flags=...) at eventdispatchers/qunixeventdispatcher.cpp:68
#31 0x00007f5cac2f0cea in QEventLoop::exec (this=this@entry=0x7ffe95643980, flags=..., flags@entry=...) at kernel/qeventloop.cpp:210
#32 0x00007f5cac2f92fc in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1261
#33 0x00007f5cac63bd9c in QGuiApplication::exec () at kernel/qguiapplication.cpp:1639
#34 0x00007f5cacbde7f5 in QApplication::exec () at kernel/qapplication.cpp:2975
#35 0x00007f5cae75d133 in kdemain (argc=2, argv=0x7ffe95643c18) at /home/martin/src/kde/workspace/kwin/main_x11.cpp:467
#36 0x00007f5cae3ab830 in __libc_start_main (main=0x400710 <main(int, char**)>, argc=2, argv=0x7ffe95643c18, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe95643c08) at ../csu/libc-start.c:291
#37 0x0000000000400749 in _start ()

The wait_for_special_event looks very suspicious
Comment 2 Fabian Vogt 2016-11-17 10:48:20 UTC
Found a workaround: LIBGL_DRI3_DISABLE=1 kwin_x11 --replace
Unfortunately it causes lots of weird rendering glitches, so not usable...

Some resources:
https://bugs.freedesktop.org/show_bug.cgi?id=84252
https://bugs.freedesktop.org/show_bug.cgi?id=94108

Seems to be a bug in libxcb/Mesa or the combination with Qt...
Comment 3 Martin Flöser 2016-11-17 11:16:43 UTC
wonderful :-(

What I currently try to understand is why the QtQuick window in PresentWindows triggers it, but other QtQuick windows don't (e.g. I fail to reproduce with DesktopGrid and Alt+Tab). Maybe there is a way to workaround.
Comment 4 Martin Flöser 2016-11-17 11:41:54 UTC
Created attachment 102271 [details]
Possible workaround

Attached a workaround with which I am no longer able to trigger the freeze.
Comment 5 Fabian Vogt 2016-11-21 15:18:30 UTC
(In reply to Martin Gräßlin from comment #4)
> Created attachment 102271 [details]
> Possible workaround
> 
> Attached a workaround with which I am no longer able to trigger the freeze.

Still works fine here, hasn't caused any nuclear meltdown yet. From my side that's good enough ;-)
Comment 6 Fabian Vogt 2016-11-22 15:03:40 UTC
(In reply to Fabian Vogt from comment #5)
> (In reply to Martin Gräßlin from comment #4)
> > Created attachment 102271 [details]
> > Possible workaround
> > 
> > Attached a workaround with which I am no longer able to trigger the freeze.
> 
> Still works fine here, hasn't caused any nuclear meltdown yet. From my side
> that's good enough ;-)

Meh, I have to correct that: Occasionally I can see the close icon for a few frames after the effect is over.
Comment 7 Martin Flöser 2017-01-24 18:06:16 UTC
*** Bug 375504 has been marked as a duplicate of this bug. ***
Comment 8 Pascal d'Hermilly 2017-01-30 14:05:16 UTC
I confirm this for 5.8.5 as well.
Sometimes the same lag appears just after having triggered the present windows.
Comment 9 grouchomarx.fr 2017-02-05 19:31:13 UTC
I don't know if this is helpful, but I can reproduce it just by hovering the mouse cursor over the close button and quickly move it away from the active window (before the animation of the close button has completed).
Comment 10 Fabian Vogt 2017-03-11 17:08:41 UTC
Created attachment 104509 [details]
Other possible workaround

I made a different workaround that is less hacky than the one attached by mgraesslin and it seems to work reliably here.
Comment 11 Fabian Vogt 2017-03-11 17:30:42 UTC
(In reply to Fabian Vogt from comment #10)
> Created attachment 104509 [details]
> Other possible workaround
> 
> I made a different workaround that is less hacky than the one attached by
> mgraesslin and it seems to work reliably here.

Just confirmed what I feared: Does not work on wayland as it should. As the bug only happens on X, maybe the workaround can be used depending on the platform?
Comment 12 Martin Flöser 2017-03-12 16:55:08 UTC
> Just confirmed what I feared: Does not work on wayland as it should.

I assume the problem is the mask not working?

> As the bug
> only happens on X, maybe the workaround can be used depending on the
> platform?

Difficult, the effects don't have the windowing system exposed yet.
Comment 13 Fabian Vogt 2017-03-12 19:08:17 UTC
(In reply to Martin Gräßlin from comment #12)
> > Just confirmed what I feared: Does not work on wayland as it should.
> 
> I assume the problem is the mask not working?

Correct, the close button stays visible after closing the effect.

> > As the bug
> > only happens on X, maybe the workaround can be used depending on the
> > platform?
> 
> Difficult, the effects don't have the windowing system exposed yet.

I found this, wouldn't a test like this work:

>    KWayland::Server::Display *display = effects->waylandDisplay();
>    if (display) {
>        display->createSlideManager(this)->create();
>    }
Comment 14 Martin Flöser 2017-03-12 19:37:37 UTC
Am 12. März 2017 20:08:17 MEZ schrieb Fabian Vogt <bugzilla_noreply@kde.org>:
>https://bugs.kde.org/show_bug.cgi?id=372576
>
>--- Comment #13 from Fabian Vogt <fabian@ritter-vogt.de> ---
>(In reply to Martin Gräßlin from comment #12)
>> > Just confirmed what I feared: Does not work on wayland as it
>should.
>> 
>> I assume the problem is the mask not working?
>
>Correct, the close button stays visible after closing the effect.

Yep, a lacking features in KWin's own qpa plugin.

>
>> > As the bug
>> > only happens on X, maybe the workaround can be used depending on
>the
>> > platform?
>> 
>> Difficult, the effects don't have the windowing system exposed yet.
>
>I found this, wouldn't a test like this work:
>
>>    KWayland::Server::Display *display = effects->waylandDisplay();
>>    if (display) {
>>        display->createSlideManager(this)->create();
>>    }

Only if we assume that we will never have a wayland display on X11. And I have an experimental branch to support that ;-)
Comment 15 Elvis Angelaccio 2017-04-13 21:15:17 UTC
Not sure what changed (possibly a xorg update in the archlinux package), but I'm no longer able to reproduce this issue on X11.
Comment 16 Elvis Angelaccio 2017-04-14 06:44:07 UTC
(In reply to Elvis Angelaccio from comment #15)
> Not sure what changed (possibly a xorg update in the archlinux package), but
> I'm no longer able to reproduce this issue on X11.

Nevermind, I think it's related to https://bugs.kde.org/show_bug.cgi?id=378762

If I try with another user (not affacted by the bug above), I can still reproduce the lag when closing.
Comment 17 Wyatt Childers 2017-06-08 23:52:13 UTC
I have noticed this issue as well. On my home computer -- AMD open source graphics -- this does not happen, at all. On my work computer -- Intel open source graphics -- this happens frequently, both when closing windows, and opening the present windows effect.
Comment 18 mentis.by 2017-06-29 22:26:32 UTC
I can reproduce this on Kde Neon 5.10.3 with intel drivers. Very annoying bug :(
Comment 19 Fernando 2017-10-23 14:12:22 UTC
Also in Kubuntu 17.10 with KDE Plasma 5.10.5.
Comment 20 Martin Flöser 2018-02-08 17:48:57 UTC
*** Bug 390088 has been marked as a duplicate of this bug. ***
Comment 21 Matthieu Gras 2018-07-26 12:55:12 UTC
https://imgur.com/a/mUiyMuI

Same problem in kwin 5.13.3
Comment 22 r.kunschke 2018-09-09 08:16:33 UTC
I can confirm this with plasma 5.13.5-2 on Arch wit Intel HD graphics. It happens only on close and not on searching in the present window view.
Comment 23 cdancette 2018-12-01 06:28:44 UTC
I can confirm this with Plasma 5.12.6 (Kubuntu 18.04), with Intel HD graphics.
Comment 24 taocrismon 2018-12-08 14:24:35 UTC
Can confirm this on Plasma 5.14.3, Fedora 29 with Intel graphics & modesetting DDX.
Hovering on the close button produces the lag as well.
Comment 25 Madhav Kanbur 2019-02-10 05:27:43 UTC
Still present in Plasma 15.14.5, Arch linux, intel modesetting. It's been almost 2 years since this bug was reported. I know that it's not a major bug, but it sure is annoying for intel users. Can we please get the workaround merged? Thanks
Comment 26 Martin Flöser 2019-02-10 07:54:39 UTC
I don't think we will add a workaround. This issue is only present on one driver on X11. With the same driver on Wayland this issue doesn't exist. Adding a workaround has the risk of breakage in other areas. As we are feature Frozen on X11 and most devs are on Wayland I at least consider the risk of breakage as too high.
Comment 27 David Edmundson 2019-02-10 12:06:14 UTC
There was a hang caused by xcb when used in a threaded context (which the QtQuick close button would do on some drivers) which was fixed very recently by nvidia.

Would be worth someone who can reliably reproduce this trying to backport bbda345a718ff73086437e51f03fcbb73e4365b9 in libxcb.
Comment 28 Patrick Silva 2019-03-10 20:20:39 UTC
*** Bug 405178 has been marked as a duplicate of this bug. ***
Comment 29 Ayan 2019-03-26 13:42:04 UTC
What's the current status of this issue. Is this gonna be fixed in upcoming kde version or there is no timeline for it?
Comment 30 Christoph Feck 2019-04-19 09:54:59 UTC
Ayan, please check with your distribution if xcb has the commit mentioned in comment #27. But I agree with comment #26, and this bug should be closed; it's not our bug.
Comment 31 Stoyan Stoyanov 2019-06-10 08:13:19 UTC
Can someone confirm if the fix mentioned in comment 27 will be included in feature updates in KDE Neon?
Comment 32 Rafał 2019-06-13 13:25:59 UTC
I'm still experiencing this issue on intel drivers too.
Comment 33 Michał Dybczak 2019-06-21 16:54:01 UTC
I also notice this bug on Intel X session from a long time. On Wayland or Nvidia all works fluently and Overview is pleasant to use, but not on Intel Xorg (which I use most of the time).

Since Xorg will be used for many, many years (wayland session is a disaster in the latest 5.16 update, not even possible to test anymore because of some pretty heavy memory leak) and Intel is still widely used, this is a very annoying bug.
Comment 34 Michał Dybczak 2019-06-24 21:40:11 UTC
Wow, I commented here 3 days ago (bug was present for me since always, at least few years) and some update in meantime seemed to fix the bug!!! There is no lag on intel X session and it all works fluently like on Nvidia or in Wayland! Awesome!

The only update that looks like could bring that fix was qt5-base 5.12.4-2.1 or kwin 5.16.1-4.

Can anyone on Arch or Manjaro unstable also confirm that there is no lag anymore?
Comment 35 Patrick Silva 2019-06-24 22:23:41 UTC
Yes, the problem is solved on my Arch too. \o/
I use intel hd graphics.
Comment 36 Nate Graham 2019-06-25 07:32:10 UTC
Woohoo!
Comment 37 Stoyan Stoyanov 2019-06-25 07:37:30 UTC
I can confirm, bug is gon on my XPS 13 9350 with i5 :) Awesome!
Comment 38 Pascal d'Hermilly 2019-06-25 13:38:42 UTC
Mostly gone. You can still trigger it by moving the mouse in and out over the close icon of the window.
It almost feels like it's some bad connection between the animation of the close icon and the enlarge window under mouse animation.
Comment 39 Stoyan Stoyanov 2019-06-25 16:32:00 UTC
A(In reply to Pascal d'Hermilly from comment #38)
> Mostly gone. You can still trigger it by moving the mouse in and out over
> the close icon of the window.
> It almost feels like it's some bad connection between the animation of the
> close icon and the enlarge window under mouse animation.

Actually you are right! Sorry about my previous comment - the bug is still existing on XPS 13 9350 although the bad animation on hover does feel different :(
Comment 40 Michał Dybczak 2019-06-27 08:53:00 UTC
This seems to be an entirely different issue because I can't confirm it. All is super fluent and there no lag whatsoever on my site (Alienware 17 R3, Intel i7-6700HQ, proprietary driver). Moving cursor in/out over the close icon isn't changing that, all fluent.

So I guess, for some this another issue will be present and we would have to figure it out anew what is the cause, why for some this is present.

I noticed that the close icon changes with the theme (probably icon theme?) so this new lag bug may be related to this.

Try changing themes and see if it made any difference. Also, install all depended icon themes, because the often problem is, we install an icon theme that relies on other icon themes and without them system falls back to another set. That can possibly create other lag issues as I suspect, so the best way is to set default themes or colors for the experiment.
Comment 41 Pascal d'Hermilly 2019-06-27 11:34:36 UTC
@michael Just to be clear. it's not enough just to hover on and off over the close icon - you have to trigger window enlarge/shrink effect(mouse hover in/out of window) to get the lag.

I didn't mess with the themes: it's Breeze on Intel graphics.

Enabling the FPS desktop effect shows me a drop from 60FPS to 1FPS during the lag.
Comment 42 Michał Dybczak 2019-06-27 17:40:16 UTC
Still can't reproduce it. The original bug was a lag when closing windows in the overview mode. This is different, at least from the description. The underlying cause may be similar, although if that is not reproducible for everyone it suggests something different.

It would be good to create a video of this new (version of) bug and gather new confirmations from various persons. So basically new bug report.

Again, I'm using overview now more often (since there is no lag) and can't see any problems with it, it's a smooth experience across the board for me.
Comment 43 Salvo "LtWorf" Tomaselli 2019-06-28 06:11:10 UTC
Hello,

I don't know what version people are using, but I am using debian unstable and the issue is still there.

When the close button is pressed within the present windows effect, it starts lagging badly. This has always been the bug, for several years.

I can still reproduce it 100% of the times that I close a window during present windows.

I use intel and debian sid.
Comment 44 Michał Dybczak 2019-06-28 09:05:34 UTC
I'm unfamiliar with Debian, but I suspect it's delayed compared to distros like Arch or Manjaro or Suse Thumbleweed and the fix arrived just yet so most probably you don't have it yet.

Check if you have this version of packages (which are likely having the fix, although this isn't confirmed):

qt5-base 5.12.4-2.1
kwin 5.16.1-4.


By the way, we already have a newer version of kwin, so things move rapidly. From what I heard, Debian unstable is not like a typical rolling distro, whatever that means.
Comment 45 David 2019-06-28 10:01:15 UTC
Debian sid is still at 5.14.5 of KDE and Kwin. So you won't see the fix for a while. At the moment everything is still in the freeze stage for the next major release.