Bug 452119

I also use the iGPU of an haswell cpu (celeron g1820) and can confirm worse performance on Wayland compared to X11.
Even video playback is laggy with several different players despite VAAPI acceleration is working according to vainfo command. Disabling blur effect improved the situation a bit on my system at least.

My versions:

Operating System: Arch Linux
KDE Plasma Version: 5.24.4
KDE Frameworks Version: 5.92.0
Qt Version: 5.15.3
Kernel Version: 5.17.1-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 2 × Intel® Celeron® CPU G1820 @ 2.70GHz
Memory: 7,6 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics

> But what REALLY helps, is enabling the Show FPS effect

Does the GPU or memory clock go up if you enable it?

(In reply to Zamundaaa from comment #3)
> > But what REALLY helps, is enabling the Show FPS effect
> 
> Does the GPU or memory clock go up if you enable it?

If I remember right, it goes from 2mhz to about 200mhz.
I'll check it by monday.

(In reply to Zamundaaa from comment #3)
> > But what REALLY helps, is enabling the Show FPS effect
> 
> Does the GPU or memory clock go up if you enable it?

Enabling show fps effects bump the gpu use to about 150mhz.
Which is a weird value, because the lowest non-idle setting should be 200mhz, so i suspect it is averaging results.
By the way,  the desktop is almost smooth everytime with show fps effeca and with lowest latency.

However if i turn off "show fps" and artificially put the gpu mhz to a higher value state with glxgears to 200mhz, then while it is a bit better than without glxgears, it is definitely not smooth as with the show fps effect running, so i suspect is not just a matter of gpu idling too much.

What does the memory clock do with the fps effect? GPU core clock is not the single deciding factor on performance

(In reply to Zamundaaa from comment #6)
> What does the memory clock do with the fps effect? GPU core clock is not the
> single deciding factor on performance

If you are asking me, I've no idea.
I answered to your previous question: "Does the GPU or memory clock go up if you enable it?"
I don't know which go up when i enable the Show FPS effect, because intel gpu utils refers to a generic "gpu frequency".
However, since you asked about one of those frequencies, i answered Yes, because intel_gpu_top reports an higher frequency when i enable FPS effect.
Note that the actual minimum frequency for non idle state is 200mhz; in idle state the gpu reaches 1mhz.
If when i enable FPS effect i get something lower, it probabily means that it is just waking up the gpu from time to time.

Could you please  be more specific? I'm having hard times trying to understand your point.

Aye, i've read better, sorry.
I don't know how to read current memory clock speed. Do you have advices?

I don't know how to check the memory clock on Intel systems, searching for it doesn't yield results for the dynamic memory speed either.

We can just check for it differently though: If you start glxgears and leave that running instead of the fps effect, does that make KWin run smooth?

(In reply to Zamundaaa from comment #9)
> I don't know how to check the memory clock on Intel systems, searching for
> it doesn't yield results for the dynamic memory speed either.
> 
> We can just check for it differently though: If you start glxgears and leave
> that running instead of the fps effect, does that make KWin run smooth?

Already did, please see end of comment 5.
It does, but marginally and frequency is even higher.

Created attachment 148636 [details]
sudo intel_gpu_top > x11-idle.log

Output of intel_gpu_top for an idle x11 desktop

Created attachment 148637 [details]
sudo intel_gpu_top > x11-moving-window.log

Output of intel_gpu_top for a window being moved on an X11 desktop

Created attachment 148638 [details]
sudo intel_gpu_top > wayland-idle.log

Output of intel_gpu_top for an idle Wayland desktop

Created attachment 148640 [details]
sudo intel_gpu_top > wayland-moving-window.log

Output of intel_gpu_top for a window being moved on a Wayland desktop

I also noticed a significant slowdown and increased choppiness when switching from X11 to Wayland.
I ran intel_cpu_info on both desktops and attached the output for idle desktops and while moving/dragging a chrome browser window around with the mouse. When run interactively, intel_gpu_top shows values of 1 Mhz and about 220 Mhz for the idle and moving window szenario on X11, respctively.  For Wayland, the numbers are 5-10 Mhz and about 400 Mhz.

When the output is logged to a file, the numbers look differently for idle case, though. It looks as if the frequency actually drops a lot more often to single digit values on wayland in idle, whereas it seems to stay in the 100-200 Mhz range on an idle desktop in X11.
When moving the window around, we see much higher gpu frequencies on Wayland (around 400Mhz) vs around 250Mhz on X11.
So it seems that wayland requires higher gpu frequencies and while still not achieving the smooth result of X11.

I did enable the show fps effect, but noticed only a small improvement. I did notice, however, that dragging a window around with this effect active causes much higher gpu frequencies (around 700 Mhz).

Please note, that the numbers should only be taken as an indication, as the tests were conducted using manual input/mouse movements. while other applications have been running. They do show, however, that wayland currently puts a much higher burden on this intel GPU.

I don't know much about gfx drives on linux. Is the same driver stack used for wayland vs X11? Just wondering if the likes of mesa might have an influence on this, or if this is definitely a kwin-wayland vs kwin-x11 issue.

Please let me know if there is anything else that I can do to provide more information to help get to the cause of this issue.

(In reply to Zamundaaa from comment #9)
> I don't know how to check the memory clock on Intel systems, searching for
> it doesn't yield results for the dynamic memory speed either.
> 
> We can just check for it differently though: If you start glxgears and leave
> that running instead of the fps effect, does that make KWin run smooth?

As this is a built-in GPU without dedicated memory, I don't think that the memory clock actually changes depending on the GPU load. The  memory is shared with the CPU, so the memory clock should not change.
Leaving glxgears running, it achieves about 60fps. When I start moving a window the FPS drop to about 30-40 and the window movement is still choppy and not smooth.

Integrated GPUs do very much influence the used memory frequency, it has a large effect on performance and battery life.
But glxgears running should already put memory frequency to the maximum, it certainly does that on my AMD laptop.

I'm having the same problem. Using the following setup:
Operating System: Kubuntu 22.04
KDE Plasma Version: 5.24.5
KDE Frameworks Version: 5.94.0
Qt Version: 5.15.3
Kernel Version: 5.15.0-33-generic (64-bit)
Processors: 4 × Intel® Core™ i7-4600U CPU @ 2.10GHz
Memory: 15,1 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 4400

Wayland performance was alright with Plasma 5.18.

I was experiencing this issue and found that the cause was actually Firefox forcing kwin to constantly repaint the screen; see https://bugzilla.mozilla.org/show_bug.cgi?id=1754810. Setting `widget.wayland.vsync.enabled` to `false` on Firefox's about:config page fixed the issue by making it no longer constantly repaint.

For people who are affected, by this issue, can you turn on the "Show Paint" KWin effect, set a keyboard shortcut for it, and hit that keyboard shortcut? If you see that the screen constantly flickers, then you're having the same issue of *something* forcing the screen to constantly repaint.

There might be opportunities for KWin itself to handle this better, but apps also need to cooperate.

(In reply to Nate Graham from comment #19)
> I was experiencing this issue and found that the cause was actually Firefox
> forcing kwin to constantly repaint the screen; see
> https://bugzilla.mozilla.org/show_bug.cgi?id=1754810. Setting
> `widget.wayland.vsync.enabled` to `false` on Firefox's about:config page
> fixed the issue by making it no longer constantly repaint.
> 
> For people who are affected, by this issue, can you turn on the "Show Paint"
> KWin effect, set a keyboard shortcut for it, and hit that keyboard shortcut?
> If you see that the screen constantly flickers, then you're having the same
> issue of *something* forcing the screen to constantly repaint.
> 
> There might be opportunities for KWin itself to handle this better, but apps
> also need to cooperate.

I tried what you suggested and turned on the "Show Paint" effect. The only difference between wayland an xorg seems that on wayland the screen also flickers when just moving the cursor. But the screen does not flicker constantly, so there is nothing causing constant repaints. 
I also switched to Crocus driver by setting export MESA_LOADER_DRIVER_OVERRIDE=crocus in ~/.profile but it does not help.
The same issue exists in Opensuse Leap 15.4.

Can everyone that's affected attach the output of drm_info (https://gitlab.freedesktop.org/emersion/drm_info) on their system?

Created attachment 153392 [details]
output of drm_info

Ok. Can you check if any of these environment variables (only one at a time) make a difference?
KWIN_DRM_NO_AMS=1
KWIN_DRM_USE_MODIFIERS=0
KWIN_DRM_PREFER_COLOR_DEPTH=24

Created attachment 153395 [details]
output of drm_info (Haswell-ULT Integrated Graphics Controller (rev 0b))

Here is my output of drm_info. Going to check your suggestions soon.
Thanks!

Created attachment 153399 [details]
drm_info (HD Intel® 4600)

(In reply to Zamundaaa from comment #23)
> Ok. Can you check if any of these environment variables (only one at a time)

no difference

I'm afraid this will need to be brute forced then; if performance was fine in 5.18 but not now then a bisect would be useful. As that's pretty much impossible to do over such a large range of versions, can you boot a few old ISOs on your hardware and see with what the last Plasma version is where performance was good?

I have tested the env variables by adding them to /env/environment file. Plasma animations are more fluid when I use the first two options, but video playback with mpv, vlc and gstreamer-based players is still stuttering. There is no difference with the third option.

Operating System: Arch Linux
KDE Plasma Version: 5.26.2
KDE Frameworks Version: 5.99.0
Qt Version: 5.15.7
Kernel Version: 6.0.6-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 2 × Intel® Celeron® CPU G1820 @ 2.70GHz
Memory: 7,6 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics

And kwin_wayland crashed once when I minimized a window with click on the task manager while using KWIN_DRM_USE_MODIFIERS=0



Thread 12 (Thread 0x7f15968976c0 (LWP 3945)):
#0  0x00007f15ed921096 in epoll_wait (epfd=89, events=events@entry=0x7f1596896770, maxevents=32, timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
#1  0x00007f15ab290669 in impl_pollfd_wait (object=<optimized out>, pfd=<optimized out>, ev=0x7f1596896940, n_ev=<optimized out>, timeout=<optimized out>) at ../pipewire/spa/plugins/support/system.c:157
#2  0x00007f15ab282b7b in loop_iterate (object=0x560fa85a7ae8, timeout=-1) at ../pipewire/spa/plugins/support/loop.c:401
#3  0x00007f15ee560317 in do_loop (user_data=0x560fa851df20) at ../pipewire/src/pipewire/data-loop.c:81
#4  0x00007f15ed89f8fd in start_thread (arg=<optimized out>) at pthread_create.c:442
#5  0x00007f15ed921a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 11 (Thread 0x7f15cafff6c0 (LWP 3550)):
#0  __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x7f15caffea60, op=137, expected=0, futex_word=0x560fa70ecee4) at futex-internal.c:57
#1  __futex_abstimed_wait_common (futex_word=futex_word@entry=0x560fa70ecee4, expected=expected@entry=0, clockid=clockid@entry=1, abstime=abstime@entry=0x7f15caffea60, private=private@entry=0, cancel=cancel@entry=true) at futex-internal.c:87
#2  0x00007f15ed89c51f in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x560fa70ecee4, expected=expected@entry=0, clockid=clockid@entry=1, abstime=abstime@entry=0x7f15caffea60, private=private@entry=0) at futex-internal.c:139
#3  0x00007f15ed89efd4 in __pthread_cond_wait_common (abstime=0x7f15caffea60, clockid=1, mutex=0x560fa70ece90, cond=0x560fa70eceb8) at pthread_cond_wait.c:503
#4  ___pthread_cond_timedwait64 (cond=0x560fa70eceb8, mutex=0x560fa70ece90, abstime=0x7f15caffea60) at pthread_cond_wait.c:643
#5  0x00007f15ee6eb714 in QWaitConditionPrivate::wait_relative(QDeadlineTimer) (deadline=..., this=0x560fa70ece90) at thread/qwaitcondition_unix.cpp:136
#6  QWaitConditionPrivate::wait(QDeadlineTimer) (deadline=..., this=0x560fa70ece90) at thread/qwaitcondition_unix.cpp:144
#7  QWaitCondition::wait(QMutex*, QDeadlineTimer) (this=<optimized out>, mutex=0x560fa70e7228, deadline=...) at thread/qwaitcondition_unix.cpp:225
#8  0x00007f15ee6e82b7 in QThreadPoolThread::run() (this=0x560fa70f2c30) at thread/qthreadpool.cpp:140
#9  0x00007f15ee6e42ea in QThreadPrivate::start(void*) (arg=0x560fa70f2c30) at thread/qthread_unix.cpp:330
#10 0x00007f15ed89f8fd in start_thread (arg=<optimized out>) at pthread_create.c:442
#11 0x00007f15ed921a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 10 (Thread 0x7f159e3316c0 (LWP 3929)):
#0  __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x7f159ebcb550) at futex-internal.c:57
#1  __futex_abstimed_wait_common (futex_word=futex_word@entry=0x7f159ebcb550, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at futex-internal.c:87
#2  0x00007f15ed89c51f in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x7f159ebcb550, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at futex-internal.c:139
#3  0x00007f15ed89ecd0 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x7f159ebcb500, cond=0x7f159ebcb528) at pthread_cond_wait.c:503
#4  ___pthread_cond_wait (cond=0x7f159ebcb528, mutex=0x7f159ebcb500) at pthread_cond_wait.c:618
#5  0x00007f15e250799e in cnd_wait () at ../mesa-22.2.1/src/c11/impl/threads_posix.c:135
#6  0x00007f15e24baf8c in util_queue_thread_func () at ../mesa-22.2.1/src/util/u_queue.c:287
#7  0x00007f15e25078cc in impl_thrd_routine () at ../mesa-22.2.1/src/c11/impl/threads_posix.c:67
#8  0x00007f15ed89f8fd in start_thread (arg=<optimized out>) at pthread_create.c:442
#9  0x00007f15ed921a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 9 (Thread 0x7f15ca6606c0 (LWP 3551)):
#0  0x00007f15ed9140bf in __GI___poll (fds=0x7f15b80029e0, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007f15ec6c41df in g_main_context_poll (priority=<optimized out>, n_fds=1, fds=0x7f15b80029e0, timeout=<optimized out>, context=0x7f15b8000c30) at ../glib/glib/gmain.c:4543
#2  g_main_context_iterate.constprop.0 (context=0x7f15b8000c30, block=1, dispatch=1, self=<optimized out>) at ../glib/glib/gmain.c:4233
#3  0x00007f15ec66c132 in g_main_context_iteration (context=0x7f15b8000c30, may_block=1) at ../glib/glib/gmain.c:4303
#4  0x00007f15ee8d7c4c in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x7f15b8000b70, flags=...) at kernel/qeventdispatcher_glib.cpp:423
#5  0x00007f15ee88573c in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x7f15ca65fae0, flags=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:69
#6  0x00007f15ee6e721f in QThread::exec() (this=this@entry=0x560fa7248520) at ../../include/QtCore/../../src/corelib/global/qflags.h:121
#7  0x00007f15ef6c0370 in QQmlThreadPrivate::run() (this=0x560fa7248520) at /usr/src/debug/qtdeclarative/src/qml/qml/ftw/qqmlthread.cpp:155
#8  0x00007f15ee6e42ea in QThreadPrivate::start(void*) (arg=0x560fa7248520) at thread/qthread_unix.cpp:330
#9  0x00007f15ed89f8fd in start_thread (arg=<optimized out>) at pthread_create.c:442
#10 0x00007f15ed921a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 8 (Thread 0x7f15e89ff6c0 (LWP 3544)):
#0  0x00007f15ed9140bf in __GI___poll (fds=0x7f15e40053e0, nfds=3, timeout=2018) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007f15ec6c41df in g_main_context_poll (priority=<optimized out>, n_fds=3, fds=0x7f15e40053e0, timeout=<optimized out>, context=0x7f15e4001cf0) at ../glib/glib/gmain.c:4543
#2  g_main_context_iterate.constprop.0 (context=0x7f15e4001cf0, block=1, dispatch=1, self=<optimized out>) at ../glib/glib/gmain.c:4233
#3  0x00007f15ec66c132 in g_main_context_iteration (context=0x7f15e4001cf0, may_block=1) at ../glib/glib/gmain.c:4303
#4  0x00007f15ee8d7c4c in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x7f15e4000b70, flags=...) at kernel/qeventdispatcher_glib.cpp:423
#5  0x00007f15ee88573c in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x7f15e89fead0, flags=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:69
#6  0x00007f15ee6e721f in QThread::exec() (this=this@entry=0x7f15f073f560 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at ../../include/QtCore/../../src/corelib/global/qflags.h:121
#7  0x00007f15f06e3cba in QDBusConnectionManager::run() (this=0x7f15f073f560 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at /usr/src/debug/qtbase/src/dbus/qdbusconnection.cpp:179
#8  0x00007f15ee6e42ea in QThreadPrivate::start(void*) (arg=0x7f15f073f560 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at thread/qthread_unix.cpp:330
#9  0x00007f15ed89f8fd in start_thread (arg=<optimized out>) at pthread_create.c:442
#10 0x00007f15ed921a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 7 (Thread 0x7f15c8a456c0 (LWP 3554)):
#0  0x00007f15ed9140bf in __GI___poll (fds=0x7f15bc0029e0, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007f15ec6c41df in g_main_context_poll (priority=<optimized out>, n_fds=1, fds=0x7f15bc0029e0, timeout=<optimized out>, context=0x7f15bc000c30) at ../glib/glib/gmain.c:4543
#2  g_main_context_iterate.constprop.0 (context=0x7f15bc000c30, block=1, dispatch=1, self=<optimized out>) at ../glib/glib/gmain.c:4233
#3  0x00007f15ec66c132 in g_main_context_iteration (context=0x7f15bc000c30, may_block=1) at ../glib/glib/gmain.c:4303
#4  0x00007f15ee8d7c4c in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x7f15bc000b70, flags=...) at kernel/qeventdispatcher_glib.cpp:423
#5  0x00007f15ee88573c in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x7f15c8a44ae0, flags=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:69
#6  0x00007f15ee6e721f in QThread::exec() (this=this@entry=0x560fa7b80150) at ../../include/QtCore/../../src/corelib/global/qflags.h:121
#7  0x00007f15ef6c0370 in QQmlThreadPrivate::run() (this=0x560fa7b80150) at /usr/src/debug/qtdeclarative/src/qml/qml/ftw/qqmlthread.cpp:155
#8  0x00007f15ee6e42ea in QThreadPrivate::start(void*) (arg=0x560fa7b80150) at thread/qthread_unix.cpp:330
#9  0x00007f15ed89f8fd in start_thread (arg=<optimized out>) at pthread_create.c:442
#10 0x00007f15ed921a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 6 (Thread 0x7f15c929c6c0 (LWP 3553)):
#0  __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x7f15c929d550) at futex-internal.c:57
#1  __futex_abstimed_wait_common (futex_word=futex_word@entry=0x7f15c929d550, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at futex-internal.c:87
#2  0x00007f15ed89c51f in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x7f15c929d550, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at futex-internal.c:139
#3  0x00007f15ed89ecd0 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x7f15c929d500, cond=0x7f15c929d528) at pthread_cond_wait.c:503
#4  ___pthread_cond_wait (cond=0x7f15c929d528, mutex=0x7f15c929d500) at pthread_cond_wait.c:618
#5  0x00007f15e250799e in cnd_wait () at ../mesa-22.2.1/src/c11/impl/threads_posix.c:135
#6  0x00007f15e24baf8c in util_queue_thread_func () at ../mesa-22.2.1/src/util/u_queue.c:287
#7  0x00007f15e25078cc in impl_thrd_routine () at ../mesa-22.2.1/src/c11/impl/threads_posix.c:67
#8  0x00007f15ed89f8fd in start_thread (arg=<optimized out>) at pthread_create.c:442
#9  0x00007f15ed921a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 5 (Thread 0x7f15d8bfe6c0 (LWP 3549)):
#0  __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x7f15d9e9b550) at futex-internal.c:57
#1  __futex_abstimed_wait_common (futex_word=futex_word@entry=0x7f15d9e9b550, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at futex-internal.c:87
#2  0x00007f15ed89c51f in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x7f15d9e9b550, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at futex-internal.c:139
#3  0x00007f15ed89ecd0 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x7f15d9e9b500, cond=0x7f15d9e9b528) at pthread_cond_wait.c:503
#4  ___pthread_cond_wait (cond=0x7f15d9e9b528, mutex=0x7f15d9e9b500) at pthread_cond_wait.c:618
#5  0x00007f15e250799e in cnd_wait () at ../mesa-22.2.1/src/c11/impl/threads_posix.c:135
#6  0x00007f15e24baf8c in util_queue_thread_func () at ../mesa-22.2.1/src/util/u_queue.c:287
#7  0x00007f15e25078cc in impl_thrd_routine () at ../mesa-22.2.1/src/c11/impl/threads_posix.c:67
#8  0x00007f15ed89f8fd in start_thread (arg=<optimized out>) at pthread_create.c:442
#9  0x00007f15ed921a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 4 (Thread 0x7f15d93ff6c0 (LWP 3548)):
#0  __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x7f15e22eb550) at futex-internal.c:57
#1  __futex_abstimed_wait_common (futex_word=futex_word@entry=0x7f15e22eb550, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at futex-internal.c:87
#2  0x00007f15ed89c51f in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x7f15e22eb550, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at futex-internal.c:139
#3  0x00007f15ed89ecd0 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x7f15e22eb500, cond=0x7f15e22eb528) at pthread_cond_wait.c:503
#4  ___pthread_cond_wait (cond=0x7f15e22eb528, mutex=0x7f15e22eb500) at pthread_cond_wait.c:618
#5  0x00007f15e250799e in cnd_wait () at ../mesa-22.2.1/src/c11/impl/threads_posix.c:135
#6  0x00007f15e24baf8c in util_queue_thread_func () at ../mesa-22.2.1/src/util/u_queue.c:287
#7  0x00007f15e25078cc in impl_thrd_routine () at ../mesa-22.2.1/src/c11/impl/threads_posix.c:67
#8  0x00007f15ed89f8fd in start_thread (arg=<optimized out>) at pthread_create.c:442
#9  0x00007f15ed921a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 3 (Thread 0x7f15daf566c0 (LWP 3546)):
#0  __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x560fa6e0bac8) at futex-internal.c:57
#1  __futex_abstimed_wait_common (futex_word=futex_word@entry=0x560fa6e0bac8, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at futex-internal.c:87
#2  0x00007f15ed89c51f in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x560fa6e0bac8, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at futex-internal.c:139
#3  0x00007f15ed89ecd0 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x560fa6e0ba78, cond=0x560fa6e0baa0) at pthread_cond_wait.c:503
#4  ___pthread_cond_wait (cond=0x560fa6e0baa0, mutex=0x560fa6e0ba78) at pthread_cond_wait.c:618
#5  0x00007f15e250799e in cnd_wait () at ../mesa-22.2.1/src/c11/impl/threads_posix.c:135
#6  0x00007f15e24baf8c in util_queue_thread_func () at ../mesa-22.2.1/src/util/u_queue.c:287
#7  0x00007f15e25078cc in impl_thrd_routine () at ../mesa-22.2.1/src/c11/impl/threads_posix.c:67
#8  0x00007f15ed89f8fd in start_thread (arg=<optimized out>) at pthread_create.c:442
#9  0x00007f15ed921a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 2 (Thread 0x7f15da7556c0 (LWP 3547)):
#0  0x00007f15ed9140bf in __GI___poll (fds=0x7f15cc0029e0, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007f15ec6c41df in g_main_context_poll (priority=<optimized out>, n_fds=2, fds=0x7f15cc0029e0, timeout=<optimized out>, context=0x7f15cc000c30) at ../glib/glib/gmain.c:4543
#2  g_main_context_iterate.constprop.0 (context=0x7f15cc000c30, block=1, dispatch=1, self=<optimized out>) at ../glib/glib/gmain.c:4233
#3  0x00007f15ec66c132 in g_main_context_iteration (context=0x7f15cc000c30, may_block=1) at ../glib/glib/gmain.c:4303
#4  0x00007f15ee8d7c4c in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x7f15cc000b70, flags=...) at kernel/qeventdispatcher_glib.cpp:423
#5  0x00007f15ee88573c in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x7f15da754b00, flags=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:69
#6  0x00007f15ee6e721f in QThread::exec() (this=<optimized out>) at ../../include/QtCore/../../src/corelib/global/qflags.h:121
#7  0x00007f15ee6e42ea in QThreadPrivate::start(void*) (arg=0x560fa6ed5a28) at thread/qthread_unix.cpp:330
#8  0x00007f15ed89f8fd in start_thread (arg=<optimized out>) at pthread_create.c:442
#9  0x00007f15ed921a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 1 (Thread 0x7f15e94120c0 (LWP 3537)):
#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1  0x00007f15ed8a16b3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2  0x00007f15ed851958 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3  0x00007f15ed83b53d in __GI_abort () at abort.c:79
#4  0x00007f15ef98bc8e in egl_provider_resolver (name=name@entry=0x7f15ef9b2008 <entrypoint_strings+2184> "eglQueryDmaBufModifiersEXT", providers=providers@entry=0x7ffed1394186, entrypoints=entrypoints@entry=0x7ffed139417c) at src/egl_generated_dispatch.c:3911
#5  0x00007f15ef98bcd0 in egl_single_resolver (provider=provider@entry=PROVIDER_EGL_EXT_image_dma_buf_import_modifiers, entrypoint_offset=<optimized out>, entrypoint_offset@entry=2184) at src/egl_generated_dispatch.c:3924
#6  0x00007f15ef98dd42 in epoxy_eglQueryDmaBufModifiersEXT_resolver () at src/egl_generated_dispatch.c:4711
#7  epoxy_eglQueryDmaBufModifiersEXT_global_rewrite_ptr (dpy=0x560fa6de8cb0, format=875713089, max_modifiers=0, modifiers=0x0, external_only=0x0, num_modifiers=0x7ffed1394230) at src/egl_generated_dispatch.c:5114
#8  0x0000560fa5c0bf01 in KWin::querySupportedModifiers (format=875713089, eglDisplay=0x560fa6de8cb0) at /usr/src/debug/kwin-5.26.2.1/src/plugins/screencast/screencaststream.cpp:323
#9  KWin::ScreenCastStream::createStream() (this=0x560fa82b9030) at /usr/src/debug/kwin-5.26.2.1/src/plugins/screencast/screencaststream.cpp:344
#10 0x0000560fa5c81d64 in KWin::ScreenCastStream::init() (this=0x560fa82b9030) at /usr/src/debug/kwin-5.26.2.1/src/plugins/screencast/screencaststream.cpp:295
#11 KWin::ScreencastManager::integrateStreams(KWaylandServer::ScreencastStreamV1Interface*, KWin::ScreenCastStream*) [clone .constprop.0] (waylandStream=0x560fa80b9ae0, stream=0x560fa82b9030, this=<optimized out>) at /usr/src/debug/kwin-5.26.2.1/src/plugins/screencast/screencastmanager.cpp:201
#12 0x00007f15ee8bda51 in QtPrivate::QSlotObjectBase::call(QObject*, void**) (a=0x7ffed1394c30, r=<optimized out>, this=0x560fa7af4b00, this=<optimized out>, r=<optimized out>, a=<optimized out>) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398
#13 doActivate<false>(QObject*, int, void**) (sender=0x560fa6d90450, signal_index=5, argv=0x7ffed1394c30) at kernel/qobject.cpp:3919
#14 0x00007f15f018a0ba in KWaylandServer::ScreencastV1Interface::windowScreencastRequested(KWaylandServer::ScreencastStreamV1Interface*, QString const&, KWaylandServer::ScreencastV1Interface::CursorMode) (this=<optimized out>, _t1=<optimized out>, _t2=<optimized out>, _t3=<optimized out>) at /usr/src/debug/build/src/kwin_autogen/IEXH3JLKNG/moc_screencast_v1_interface.cpp:349
#15 0x00007f15f04365f6 in QtWaylandServer::zkde_screencast_unstable_v1::handle_stream_window(wl_client*, wl_resource*, unsigned int, char const*, unsigned int) (client=<optimized out>, resource=<optimized out>, stream=136, window_uuid=0x560fa80b9aa0 "{b5280121-2d48-41b8-83d2-d1bc916b13ca}", pointer=1) at /usr/src/debug/build/src/wayland/qwayland-server-zkde-screencast-unstable-v1.cpp:262
#16 0x00007f15ebc424f6 in ffi_call_unix64 () at ../src/x86/unix64.S:104
#17 0x00007f15ebc3ef5e in ffi_call_int (cif=<optimized out>, fn=<optimized out>, rvalue=<optimized out>, avalue=<optimized out>, closure=<optimized out>) at ../src/x86/ffi64.c:673
#18 0x00007f15ebc41b73 in ffi_call (cif=cif@entry=0x7ffed1394e80, fn=<optimized out>, rvalue=rvalue@entry=0x0, avalue=avalue@entry=0x7ffed1394f50) at ../src/x86/ffi64.c:710
#19 0x00007f15ed282ada in wl_closure_invoke (closure=closure@entry=0x560fa80b99c0, target=<optimized out>, target@entry=0x560fa817bc40, opcode=opcode@entry=1, data=<optimized out>, data@entry=0x560fa7c2b100, flags=2) at ../wayland-1.21.0/src/connection.c:1025
#20 0x00007f15ed287010 in wl_client_connection_data (fd=<optimized out>, mask=<optimized out>, data=<optimized out>) at ../wayland-1.21.0/src/wayland-server.c:437
#21 0x00007f15ed2859e2 in wl_event_loop_dispatch (loop=0x560fa6df8eb0, timeout=<optimized out>) at ../wayland-1.21.0/src/event-loop.c:1027
#22 0x00007f15f039756a in KWaylandServer::Display::dispatchEvents() (this=<optimized out>) at /usr/src/debug/kwin-5.26.2.1/src/wayland/display.cpp:114
#23 0x00007f15ee8bda51 in QtPrivate::QSlotObjectBase::call(QObject*, void**) (a=0x7ffed1395560, r=<optimized out>, this=0x560fa6dfd090, this=<optimized out>, r=<optimized out>, a=<optimized out>) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398
#24 doActivate<false>(QObject*, int, void**) (sender=0x560fa7380d80, signal_index=3, argv=0x7ffed1395560) at kernel/qobject.cpp:3919
#25 0x00007f15ee8bf904 in QSocketNotifier::activated(QSocketDescriptor, QSocketNotifier::Type, QSocketNotifier::QPrivateSignal) (this=this@entry=0x560fa7380d80, _t1=..., _t2=<optimized out>, _t3=...) at .moc/moc_qsocketnotifier.cpp:178
#26 0x00007f15ee8bfa48 in QSocketNotifier::event(QEvent*) (this=0x560fa7380d80, e=<optimized out>) at kernel/qsocketnotifier.cpp:302
#27 0x00007f15edf78b1c in QApplicationPrivate::notify_helper(QObject*, QEvent*) (this=<optimized out>, receiver=0x560fa7380d80, e=0x7ffed1395680) at kernel/qapplication.cpp:3637
#28 0x00007f15ee88cf98 in QCoreApplication::notifyInternal2(QObject*, QEvent*) (receiver=0x560fa7380d80, event=0x7ffed1395680) at kernel/qcoreapplication.cpp:1064
#29 0x00007f15ee8d690c in QEventDispatcherUNIXPrivate::activateSocketNotifiers() (this=0x560fa6dd0910) at kernel/qeventdispatcher_unix.cpp:304
#30 0x00007f15ee8d7a01 in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=<optimized out>, flags=...) at kernel/qeventdispatcher_unix.cpp:511
#31 0x0000560fa5cba3a2 in QUnixEventDispatcherQPA::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
#32 0x00007f15ee88573c in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x7ffed1395810, flags=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:69
#33 0x00007f15ee890269 in QCoreApplication::exec() () at ../../include/QtCore/../../src/corelib/global/qflags.h:121
#34 0x00007f15eed3a112 in QGuiApplication::exec() () at kernel/qguiapplication.cpp:1870
#35 0x00007f15edf76f2a in QApplication::exec() () at kernel/qapplication.cpp:2829
#36 0x0000560fa5bdb611 in main(int, char**) (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/kwin-5.26.2.1/src/main_wayland.cpp:613

That's the same backtrace as bug 460563, it shouldn't be related to the performance problem though.

(In reply to Patrick Silva from comment #28)
> I have tested the env variables by adding them to /env/environment file.
> Plasma animations are more fluid when I use the first two options, but video
> playback with mpv, vlc and gstreamer-based players is still stuttering.
> There is no difference with the third option.
That might be something to look further into. Was the drm_info output you attached created in a Wayland session? There's some information missing in it that could be useful

Created attachment 153404 [details]
drm_info_output of celeron g1820 haswell

(In reply to Zamundaaa from comment #30)
> That's the same backtrace as bug 460563, it shouldn't be related to the
> performance problem though.
> 
> (In reply to Patrick Silva from comment #28)
> > I have tested the env variables by adding them to /env/environment file.
> > Plasma animations are more fluid when I use the first two options, but video
> > playback with mpv, vlc and gstreamer-based players is still stuttering.
> > There is no difference with the third option.
> That might be something to look further into. Was the drm_info output you
> attached created in a Wayland session? There's some information missing in
> it that could be useful

I got the previously attached output while logged in with another machine via ssh. Now I'm attaching a new output gotten locally.

Thanks. Can you also attach the output of drm_info with the KWIN_DRM_USE_MODIFIERS=0 env var set?

Created attachment 153405 [details]
drm_info output with the KWIN_DRM_USE_MODIFIERS=0 env var set

On your hardware Mesa chooses the same buffer format and layout with and without modifiers. That's quite unexpected, there's nothing here that could cause a difference in performance

I tested the wayland section of gnome on my hardware and had performance problems just like with plasma.

Searching a bit more I saw that there is a version of mutter with a patch to enable the tripple buffer, and after installing it, the experience was much better.

As I understand it, kwin does not have this in wayland, correct? only in xorg.

Created attachment 153497 [details]
output of drm_info on wayland (Haswell-ULT Integrated Graphics Controller (rev 0b))

This is my drm_info output on Wayland, the first one was X11...

I just tried Fedora KDE Rawhide with Wayland, and I didn't have any issues on my Intel UHD 600. Animations were very close to 60 FPS. I have definitely seen this problem in the past. Or is Fedora doing something differently?

(In reply to Joshua T from comment #37)
> I just tried Fedora KDE Rawhide with Wayland, and I didn't have any issues
> on my Intel UHD 600. Animations were very close to 60 FPS. I have definitely
> seen this problem in the past. Or is Fedora doing something differently?

Are you unable to spot any performance degradation versus Xorg then?

(In reply to Joshua T from comment #37)
> I just tried Fedora KDE Rawhide with Wayland, and I didn't have any issues
> on my Intel UHD 600. Animations were very close to 60 FPS. I have definitely
> seen this problem in the past. Or is Fedora doing something differently?

Intel UHD 600 should not be affected as it is newer than Haswell generation graphics. So I'm not surprised that you don't have any issues.
Could you try with a different distro, like Ubuntu 20.04?

(In reply to Antonio Orefice from comment #38)
> (In reply to Joshua T from comment #37)
> > I just tried Fedora KDE Rawhide with Wayland, and I didn't have any issues
> > on my Intel UHD 600. Animations were very close to 60 FPS. I have definitely
> > seen this problem in the past. Or is Fedora doing something differently?
> 
> Are you unable to spot any performance degradation versus Xorg then?

I used the Show Kwin FPS desktop effect, and Xorg was only slightly smoother than Wayland.

(In reply to Lemmiwinks from comment #39)
> (In reply to Joshua T from comment #37)
> > I just tried Fedora KDE Rawhide with Wayland, and I didn't have any issues
> > on my Intel UHD 600. Animations were very close to 60 FPS. I have definitely
> > seen this problem in the past. Or is Fedora doing something differently?
> 
> Intel UHD 600 should not be affected as it is newer than Haswell generation
> graphics. So I'm not surprised that you don't have any issues.
> Could you try with a different distro, like Ubuntu 20.04?

I have a Celeron N4020 Gemini Lake cpu. I can confirm I had stutters and laggy animations on both Kubuntu 22.04 and 22.10.

(In reply to Joshua T from comment #40)
> (In reply to Antonio Orefice from comment #38)
> > (In reply to Joshua T from comment #37)
> > > I just tried Fedora KDE Rawhide with Wayland, and I didn't have any issues
> > > on my Intel UHD 600. Animations were very close to 60 FPS. I have definitely
> > > seen this problem in the past. Or is Fedora doing something differently?
> > 
> > Are you unable to spot any performance degradation versus Xorg then?
> 
> I used the Show Kwin FPS desktop effect, and Xorg was only slightly smoother
> than Wayland.

If you take a look at the first post, you'll read that the fps effect is not a good meter; indeed using it workarounds the issues under Wayland.

I can confirm that using the Show FPS effect makes the whole situation a lot better.
Could it be that there is some kind of CPU/GPU frequency scaling error?

I used the show FPS effect to get evidence of the performance of wayland vs xorg. The effect didn’t improve the performance in any way for me. Wayland on Fedora 38 KDE was still smooth before enabling the effect.

I'm going to add my experience with Wayland and X11 performance. I hope this can be addressed in the future. My Plasma 5.26.4 is powered by an Intel Pentium G2030T (2) 2.60GHz. I tested both X11 and Wayland with blur and contrast enabled as well as the FPS effect. I did the same tests on both X11 and Wayland, and I noticed that any blur effect that fills the entire screen makes the framerate drop as low as 40 in Wayland, while on X11 I get 60 fps with the same blurred window filling the entire screen. Also, I get higher render usage with animations and moving windows around in Wayland vs. what I get in X11. I don't think Wayland's performance should be this bad.

I think I made an observation: under System Settings -> Compositor, setting the latency to "force smoothest animations", seems to almost fix the problem for me. Maybe someone could try this...

(In reply to Lemmiwinks from comment #46)
> I think I made an observation: under System Settings -> Compositor, setting
> the latency to "force smoothest animations", seems to almost fix the problem
> for me. Maybe someone could try this...

The very same workaround is pointed out by the reporter in the very first post.

Git commit cf583aa3673cfca275b64d25c457d9e4a298c46c by Nate Graham, on behalf of Vlad Zahorodnii.
Committed on 17/01/2023 at 04:10.
Pushed by ngraham into branch 'master'.

Change default latency policy to "Force smoothest animations"

There are some performance differences between X11 and Wayland. Desktop
systems are mostly unaffected by them, but laptops suffer a bit.

On Wayland, kwin always does double buffering. This is great for
reducing latency and avoiding tearing, but if the gpu can't keep up with
the work, you're going to see stuttering.

Another issue is that in order to reduce latency, we need to have very
good frame stats. At the moment, kwin records only cpu render time, but
we also need to record the gpu time. We've already done some work in
this area, but it's most likely Plasma 6 material. (plasma/kwin!1163)

In the meantime, let's change the default latency policy to "Force
smoother animations." It's going to improve frame rate. If people care
about latency, they can change latency policy in system settings; the
option is still there.

M  +1    -1    src/kcms/compositing/kwincompositing_setting.kcfg
M  +1    -1    src/kwin.kcfg
M  +1    -1    src/options.h

https://invent.kde.org/plasma/kwin/commit/cf583aa3673cfca275b64d25c457d9e4a298c46c

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

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

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

We're getting reports from Intel iGPU users that the Wayland session is and smoother with that change in Plasma 5.27. And this is my experience as well!

I was feeling curious so I decided to do some investigation and measuring. From what I can tell using intel_gpu_top, here's what's going on with my Intel HD 620 GPU:

On both X11 and Wayland, the GPU's clock speed is always below 20 MHz at idle (and frequently 0MHz), which mean the GPU is idling. In this state it reports using about 1.3 watts of power.

On X11, when I open the Overview Effect with Meta+W, the GPU immediately comes out of idle and the clock speed jumps to 300+ MHz. The animation is always smooth.

On Wayland, when I do this the GPU comes out of idle and the clock speed jumps to 600+ MHz, and even when using the new default setting of "Force smoothest animations", it's not quite as smooth as on X11. Sometimes it's close, sometimes it's less close. It's better than it was before, but still not quiiiiite as good as on X11.

When I turn on the Show FPS effect, an animation is constantly played and minimum GPU clock speed jumps to about 80 MHz. The power consumption is slightly higher at about 1.55 watts. The GPU now constantly has work to do and doesn't idle anymore; in this state, newly-played animations are as smooth as on X11.

So it seems like there is a difference on X11 vs Wayland regarding how the GPU handles coming out of an idle state. On X11 it does this quickly enough that a newly requested animation is smooth. On Wayland, that's not the case, and to replicate the same results, you have to force it to not go idle. The cost in power consumption to do so is small, but measurable. And on a laptop, it would be impactful.

I don't have enough information to speculate about whether this is a GPU driver bug, and/or if it's something KWin can do better about.

Regardless, the differences between X11 and Wayland in smoothness are now much smaller than they were before, even if we're not 100% of the way there I'm removing this bug from https://community.kde.org/Plasma/Wayland_Showstoppers since such a small difference in performance is not a showstopper.

I'm using kwin 5.27.2, but the performance on wayland is still much worse than kwin-x11, especially when blur effect is enabled.

Wayland is slow and laggy compared to X11 on my two laptops with i3-5005u and i3-1005G1.

There's a plan to try triple buffering on kwin_wayland; see https://invent.kde.org/plasma/kwin/-/issues/124. That should help, as it's what KWin does on X11 which does help with smoothness.

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

Can reporters here confirm if performance improves if the effect "background contrast" is disabled?

...And if the issue does go away with that effect disabled, then the issue was probably Bug 469151 which has just been fixed!

(In reply to David Edmundson from comment #57)
> Can reporters here confirm if performance improves if the effect "background
> contrast" is disabled?

Unfortunately, I'm currently away for a longer time from my computer. Therefore I cannot check, if enabling or disabling the effect makes any difference. Generally, I don't have any effects active in order to put as little strain on the GPU (and CPU) as possible, so I __THINK__ that I am experiencing the slower and more sluggish performance on Wayland vs Xorg without having this effect enabled. I cannot comment, however, if the performance would be even worse if I had enabled this effect.  I will check as soon as I get back to the computer.
And while I am at it, a big THANK YOU for looking into this issue :-)

(In reply to Nate Graham from comment #58)
> ...And if the issue does go away with that effect disabled, then the issue
> was probably Bug 469151 which has just been fixed!

It doesn't differ too much with Background contrast effect, on the other hand it seems disabling Blur makes really animations much smoother, especially with Task Manager thumbnails.
And one thing to note is that mouse lagging seems to be somehow improved without needing to add KWIN_DRM_NO_AMS=1 as env var.

The problem is that Wayland when idle looks good and smooth but starts to greatly slow down animations when you open some apps, and some apps are randomly frozen (grayed effect) and you need to wait for them to finish their works, I don't know if it's coming from my weak CPU, but on X11 the balance between heavy loading and animations seems much better handled than Wayland.

Created attachment 159927 [details]
settings

What do these three dots mean? Is it activated or not?

There's a tri-state based on whether it's enabled in user settings but not enabled by the compositor or something.

It's very confusing, just click it again to get to a solid checkmark or blank.

I'm using this env variable on my system:

KWIN_DRM_USE_MODIFIERS=0

Performance is the same on both Wayland and X11 sessions regardless the background contrast and blur effects are enabled or not.

Operating System: Arch Linux 
KDE Plasma Version: 5.27.6
KDE Frameworks Version: 5.107.0
Qt Version: 5.15.10
Kernel Version: 6.3.9-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 4 × Intel® Core™ i5-4670K CPU @ 3.40GHz
Memory: 15,5 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 4600
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: B85M-D3PH

glxgears test slightly stutters on Wayland.

My results on Wayland, with "blur" and "background contrast" effects disabled:

$ glxgears
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
295 frames in 5.0 seconds = 58.996 FPS
290 frames in 5.0 seconds = 57.807 FPS
290 frames in 5.0 seconds = 57.808 FPS
289 frames in 5.0 seconds = 57.799 FPS
291 frames in 5.0 seconds = 58.007 FPS
289 frames in 5.0 seconds = 57.800 FPS
290 frames in 5.0 seconds = 57.808 FPS
290 frames in 5.0 seconds = 57.807 FPS
290 frames in 5.0 seconds = 57.996 FPS
291 frames in 5.0 seconds = 58.006 FPS
289 frames in 5.0 seconds = 57.796 FPS
291 frames in 5.0 seconds = 58.006 FPS
289 frames in 5.0 seconds = 57.794 FPS
290 frames in 5.0 seconds = 57.954 FPS
291 frames in 5.0 seconds = 57.866 FPS
290 frames in 5.0 seconds = 57.997 FPS
290 frames in 5.0 seconds = 57.809 FPS
291 frames in 5.0 seconds = 58.008 FPS
290 frames in 5.0 seconds = 57.999 FPS
290 frames in 5.0 seconds = 57.995 FPS
288 frames in 5.0 seconds = 57.599 FPS
291 frames in 5.0 seconds = 58.004 FPS
290 frames in 5.0 seconds = 57.997 FPS
290 frames in 5.0 seconds = 57.812 FPS
288 frames in 5.0 seconds = 57.599 FPS

My results on X11, also with "blur" and "background contrast" effects disabled:

$ glxgears
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
294 frames in 5.0 seconds = 58.792 FPS
301 frames in 5.0 seconds = 59.998 FPS
300 frames in 5.0 seconds = 59.969 FPS
301 frames in 5.0 seconds = 60.027 FPS
301 frames in 5.0 seconds = 60.000 FPS
300 frames in 5.0 seconds = 59.999 FPS
300 frames in 5.0 seconds = 59.999 FPS
300 frames in 5.0 seconds = 59.999 FPS
301 frames in 5.0 seconds = 60.000 FPS
300 frames in 5.0 seconds = 59.998 FPS
301 frames in 5.0 seconds = 60.004 FPS
300 frames in 5.0 seconds = 59.997 FPS

(In reply to David Edmundson from comment #57)
> Can reporters here confirm if performance improves if the effect "background
> contrast" is disabled?

It helps a bit with my poweroff screen performance, but it's not enough.

(In reply to Nate Graham from comment #55)
> There's a plan to try triple buffering on kwin_wayland; see
> https://invent.kde.org/plasma/kwin/-/issues/124. That should help, as it's
> what KWin does on X11 which does help with smoothness.

Though that's only used on intel according to that page, so it doesn't explain the difference on AMD.

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

It's even worse on llvmpipe. My laptop fell back to llvmpipe after an update now for some reason, and it runs at about 1-2 FPS.

Let's keep this bug report about Intel iGPUs. If performance is worse than expected with AMD or llvmpipe, please file a separate bug report.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/4268

(In reply to Zamundaaa from comment #68)
> Let's keep this bug report about Intel iGPUs. If performance is worse than
> expected with AMD or llvmpipe, please file a separate bug report.

I have made a report about AMD at https://bugs.kde.org/show_bug.cgi?id=464520, and it was marked as a duplicate of this one

Git commit 4ad5670ddfcd7400c8b84c12cbf8bd97a0590f43 by Xaver Hugl.
Committed on 07/12/2023 at 14:17.
Pushed by zamundaaa into branch 'master'.

backends/drm: set dma-fence deadlines if available

This tells the kernel when a buffer should be done rendering, which allows
it to for example increase GPU clocks in order to hopefully hit our deadlines.
That in turn should reduce the amount of dropped frames

M  +27   -10   src/backends/drm/drm_buffer.cpp
M  +3    -0    src/backends/drm/drm_buffer.h
M  +9    -0    src/backends/drm/drm_commit.cpp
M  +1    -0    src/backends/drm/drm_commit.h
M  +1    -0    src/backends/drm/drm_commit_thread.cpp

https://invent.kde.org/plasma/kwin/-/commit/4ad5670ddfcd7400c8b84c12cbf8bd97a0590f43

(In reply to Zamundaaa from comment #71)
> Git commit 4ad5670ddfcd7400c8b84c12cbf8bd97a0590f43 by Xaver Hugl.
> Committed on 07/12/2023 at 14:17.
> Pushed by zamundaaa into branch 'master'.
> 
> backends/drm: set dma-fence deadlines if available
> 
> This tells the kernel when a buffer should be done rendering, which allows
> it to for example increase GPU clocks in order to hopefully hit our
> deadlines.
> That in turn should reduce the amount of dropped frames
> 
> M  +27   -10   src/backends/drm/drm_buffer.cpp
> M  +3    -0    src/backends/drm/drm_buffer.h
> M  +9    -0    src/backends/drm/drm_commit.cpp
> M  +1    -0    src/backends/drm/drm_commit.h
> M  +1    -0    src/backends/drm/drm_commit_thread.cpp
> 
> https://invent.kde.org/plasma/kwin/-/commit/
> 4ad5670ddfcd7400c8b84c12cbf8bd97a0590f43

Is it possible we can get this fix integrated in the current version of KWin? 
I think this is the major show stopper for Intel iGPU user on KDE Wayland.

(In reply to syed.talha.khalid from comment #72)
> (In reply to Zamundaaa from comment #71)
> > Git commit 4ad5670ddfcd7400c8b84c12cbf8bd97a0590f43 by Xaver Hugl.
> > Committed on 07/12/2023 at 14:17.
> > Pushed by zamundaaa into branch 'master'.
> > 
> > backends/drm: set dma-fence deadlines if available
> > 
> > This tells the kernel when a buffer should be done rendering, which allows
> > it to for example increase GPU clocks in order to hopefully hit our
> > deadlines.
> > That in turn should reduce the amount of dropped frames
> > 
> > M  +27   -10   src/backends/drm/drm_buffer.cpp
> > M  +3    -0    src/backends/drm/drm_buffer.h
> > M  +9    -0    src/backends/drm/drm_commit.cpp
> > M  +1    -0    src/backends/drm/drm_commit.h
> > M  +1    -0    src/backends/drm/drm_commit_thread.cpp
> > 
> > https://invent.kde.org/plasma/kwin/-/commit/
> > 4ad5670ddfcd7400c8b84c12cbf8bd97a0590f43
> 
> Is it possible we can get this fix integrated in the current version of
> KWin? 
> I think this is the major show stopper for Intel iGPU user on KDE Wayland.

That would be pretty sweet.  Plasma 6 release is still months away and distros will take even longer to include Plasma 6 on their own schedules.

Afaik 5.27 wouldn't really benefit from this due to how KWin submits frames to the kernel there.

(In reply to Zamundaaa from comment #74)
> Afaik 5.27 wouldn't really benefit from this due to how KWin submits frames
> to the kernel there.

Oh make sense, so is the fix Available in Beta version Plasma 6.0? Or we have to wait for it to land on next Beta Release?

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/4833

Just tried with an i5-1035g1 under wayland with its gpu that should be far more performant than my haswell, but still on the logout screen mouse cursor was stuttering (a lot) under wayland on the newer cpu and butter smooth on X11 on the aging haswell.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5390

Git commit d59451adcf8f7a4d90659a60bfbe73230091b0e3 by Xaver Hugl.
Committed on 26/03/2024 at 16:06.
Pushed by zamundaaa into branch 'master'.

effects/quickeffect: render qtquick scenes in the normal render pass

If they're rendered in prePaintScreen, the time needed to render them is not
accounted for in compositing scheduling, which may make KWin miss vblank
Related: bug 482861, bug 482034

M  +5    -0    src/effect/offscreenquickview.cpp
M  +9    -10   src/effect/quickeffect.cpp

https://invent.kde.org/plasma/kwin/-/commit/d59451adcf8f7a4d90659a60bfbe73230091b0e3

Performance is something we're constantly improving, there is nothing left in this bug report that's specific enough to keep this ticket open

FWIW, on my hardware (2020 10th gen Intel i7 with HD610 iGPU driving a 4K screen) the issue is completely resolved for me, at least until the system is under heavy load--when I think some stuttering it expected.

Git commit 40a9f08dd34948264ba5b533da5373a0a51ad3f1 by Xaver Hugl.
Committed on 24/05/2024 at 15:32.
Pushed by zamundaaa into branch 'master'.

backends/drm: allow up to two composited frames to be pending at the same time

This should improve responsiveness on setups where rendering each frame takes longer
than the refresh cycle of the display.
Related: bug 454098

M  +4    -0    src/backends/drm/drm_output.cpp

https://invent.kde.org/plasma/kwin/-/commit/40a9f08dd34948264ba5b533da5373a0a51ad3f1

Git commit 192232e8d1736307f93792ea77de80e61f746bd3 by Xaver Hugl.
Committed on 24/05/2024 at 15:59.
Pushed by zamundaaa into branch 'Plasma/6.1'.

backends/drm: allow up to two composited frames to be pending at the same time

This should improve responsiveness on setups where rendering each frame takes longer
than the refresh cycle of the display.
Related: bug 454098

M  +4    -0    src/backends/drm/drm_output.cpp

https://invent.kde.org/plasma/kwin/-/commit/192232e8d1736307f93792ea77de80e61f746bd3

This issue is completely fixed for me with Plasma 6.1, FWIW! It's super awesome.