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

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

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.

Created attachment 102271 [details]
Possible workaround

Attached a workaround with which I am no longer able to trigger the freeze.

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

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

*** Bug 375504 has been marked as a duplicate of this bug. ***

I confirm this for 5.8.5 as well.
Sometimes the same lag appears just after having triggered the present windows.

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

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.

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

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

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

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

Not sure what changed (possibly a xorg update in the archlinux package), but I'm no longer able to reproduce this issue on X11.

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

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.

I can reproduce this on Kde Neon 5.10.3 with intel drivers. Very annoying bug :(

Also in Kubuntu 17.10 with KDE Plasma 5.10.5.

*** Bug 390088 has been marked as a duplicate of this bug. ***

https://imgur.com/a/mUiyMuI

Same problem in kwin 5.13.3

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.

I can confirm this with Plasma 5.12.6 (Kubuntu 18.04), with Intel HD graphics.

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.

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

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.

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.

*** Bug 405178 has been marked as a duplicate of this bug. ***

What's the current status of this issue. Is this gonna be fixed in upcoming kde version or there is no timeline for it?

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.

Can someone confirm if the fix mentioned in comment 27 will be included in feature updates in KDE Neon?

I'm still experiencing this issue on intel drivers too.

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.

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?

Yes, the problem is solved on my Arch too. \o/
I use intel hd graphics.

Woohoo!

I can confirm, bug is gon on my XPS 13 9350 with i5 :) Awesome!

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.

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

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.

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

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.

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.

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.

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.