Bug 489230 - Excessive amount of _NET_DESKTOP_GEOMETRY PropertyChange slow down the entire Xorg
Summary: Excessive amount of _NET_DESKTOP_GEOMETRY PropertyChange slow down the entire...
Status: RESOLVED DUPLICATE of bug 484323
Alias: None
Product: kwin
Classification: Plasma
Component: platform-x11-standalone (other bugs)
Version First Reported In: git-stable-Plasma/6.1
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-06-26 12:43 UTC by Maxim
Modified: 2025-07-27 13:11 UTC (History)
11 users (show)

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


Attachments
A C program that illustrates the bug (783 bytes, text/x-csrc)
2024-06-26 12:43 UTC, Maxim
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Maxim 2024-06-26 12:43:23 UTC
Created attachment 171011 [details]
A C program that illustrates the bug

SUMMARY

Starting with Plasma 6.0.3, Java-based IntelliJ IDEs may slow down the entire X session making various elements feel sluggish or unresponsive. The issue has been traced down to the generation of a huge amount of PropertyChange events for the `_NET_DESKTOP_GEOMETRY` property (https://specifications.freedesktop.org/wm-spec/1.3/ar01s03.html) when starting to drag a file from any file manager (Gnome Files in my case).
This can be seen on a simple X11 application found below. Note that the application itself is not enough to reproduce the sluggishness as it does not react to `_NET_DESKTOP_GEOMETRY` change in the same heavy-weight manner as intelliJ IDEs do.

The bug was reported by multiple users here: https://youtrack.jetbrains.com/issue/JBR-6830

STEPS TO REPRODUCE
1. Log in to a Plasma X11 desktop
2. Download PyCharm Community Edition (or any other IntelliJ IDE) https://www.jetbrains.com/pycharm/download/?section=linux
3. Run PyCharm and create an empty project
4. Open any graphical file manager
5. Start dragging a file from that file manager over PyCharm's window
6. Note how the dragged file lags behind the mouse pointer; Xorg process is at 100% CPU at this point.
7. Exit PyCharm, wait a couple of seconds
8. Start dragging a file from a file manager again
9. Note how smooth dragging is now

Alternatively, compile (`gcc -lX11 test.c`) and run the C program attached. Once executed, start dragging a file from a file manager and observe the amount of messages printed to stdout of that program.

Since the actual desktop geometry (its width and height in pixels) is the same throughout the lifetime of the application, there should not be any such events at all.

OBSERVED RESULT

Sluggish drag and lots of `Property _NET_DESKTOP_GEOMETRY changed` messages.

EXPECTED RESULT

Smooth drag and one or no `Property _NET_DESKTOP_GEOMETRY changed` messages.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Fedora 40 
(available in About System)
KDE Plasma Version: 6.1.0
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.1

ADDITIONAL INFORMATION
Also reproduces with 6.0.3 and on other Linux distros such as Arch.
Comment 1 Vlad Zahorodnii 2024-07-01 10:56:01 UTC
I've built the attached C program but I cannot reproduce the issue when dragging a file from Dolphin or nautilus
Comment 2 Adam D 2024-07-02 05:03:57 UTC
This test program does produce the problem on my original system, a KDE Neon 5 install that underwent updates and received the Plasma 6 (and of course KDE Neon 6) release. I switched to using Kubuntu for some time to avoid it as I assumed it was an issue with Plasma 6.

However, downloading and installing the latest release of KDE Neon today on the same hardware does not produce the bug. Could it be possibly related to the upgrade process?
Comment 3 kde 2024-07-02 06:29:43 UTC
Hi there. I'm using IntelliJ Ultimate for my daily business on Manjaro.

After updating Plasma 5 to version 6, IntelliJ became unusable in my multi display setup. Unplugging all external displays solved the issue, but that's not an option to me.

A couple a days ago I set up a new machine. Since I set up IntelliJ with an OpenJDK instead of the JBR, I did not run into that issue so far.

But I read the comment wondering about if it may be an issue of the Plasma update process. On this new machine I started with Plasma 6, so I just gave that idea a try and started IntelliJ without all the workarounds. As a result I got an IDE that was quite usable, but still had issues especially with animations fading in and out the menu bar menus or dialogs. I configured only a couple of Manjaro settings, animation settings have not been changed by me.

It's still a recognizable improvement running the IDE with that custom IDE setting (-Dwatch.desktop.geometry=false) and the custom JBR provided in that JetBrains issue linked with this KDE issue.
Comment 4 Reg 2024-07-13 12:16:01 UTC
(In reply to Vlad Zahorodnii from comment #1)
> I've built the attached C program but I cannot reproduce the issue when
> dragging a file from Dolphin or nautilus

FYI: I tried this with both Wayland and X11. It's only an issue with X11 on my system.
Comment 5 Vlad Zahorodnii 2024-07-15 09:16:01 UTC
(In reply to Reg from comment #4)
> (In reply to Vlad Zahorodnii from comment #1)
> > I've built the attached C program but I cannot reproduce the issue when
> > dragging a file from Dolphin or nautilus
> 
> FYI: I tried this with both Wayland and X11. It's only an issue with X11 on
> my system.

I've tested it in Plasma X11 session as well.
Comment 6 Reg 2024-07-21 09:49:10 UTC
> I've tested it in Plasma X11 session as well.

I don't know if it would make a difference but I have all the fancy wobbly windows and such turned on on my system. I also have multiple screens, 6 in 2x3 grid and one off to the side. Perhaps two or more monitors would make a difference.
Comment 7 GuangDai 2024-08-20 02:25:32 UTC
I meet the issue and solve the temporarily solve it by using the hack provided by jetbrains. 

This is still an ongoing bug, and I hope to see a better solution.
Comment 8 Vlad Zahorodnii 2024-08-21 15:05:25 UTC
For some reason kwin is bombarded with XCB_RANDR_NOTIFY_OUTPUT_CHANGE events. No screen changes are made. kwin is spammed with XCB_RANDR_NOTIFY_OUTPUT_CHANGE when opening new windows, but it's flooded with nonsensical RandR events more frequently when the dnd moves.
Comment 9 Vlad Zahorodnii 2024-08-21 15:16:03 UTC
Just to be sure, I've disabled kscreen and kwin_x11 is still bombarded with XCB_RANDR_NOTIFY_OUTPUT_CHANGE events. kwin itself has no code to trigger randr output changes.
Comment 10 Vlad Zahorodnii 2024-08-21 15:17:23 UTC
Restarting kwin_x11 fixes it getting spammed with XCB_RANDR_NOTIFY_OUTPUT_CHANGE events.
Comment 11 Vlad Zahorodnii 2024-08-21 15:19:22 UTC
... and the events resume coming in after changing the display layout in system settings
Comment 12 Vlad Zahorodnii 2024-08-21 15:43:18 UTC
The XCB_RANDR_NOTIFY_OUTPUT_CHANGE events come directly from Xorg, it doesn't appear like Qt or KWin do something wrong with the events. I suspect that it might be a Xorg bug.
Comment 13 Vlad Zahorodnii 2025-07-27 13:11:20 UTC

*** This bug has been marked as a duplicate of bug 484323 ***