https://bugs.kde.org/show_bug.cgi?id=509065

Simon Ra <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[email protected]

--- Comment #29 from Simon Ra <[email protected]> ---
I spent another 2 days hunting this down, and by now I'm confident enough to
say it's not a spectacle bug. It's a bug at the intersection of system QT,
plasmashell(plasma-workspace), and possibly kwin when dealing with the
ownership of large images in the clipboard after application exit (I tested
using around 4k resolution).

All testing was done on plasma 6.6.1/frameworks 6.23. For spectacle in
particular, I do a rectangle screenshot of most (but not all) of my two
adjacent 1440p screens. Spectacle is, of course, set to close after the
rectangle screenshot is taken. I have also tested spectacle in particular on a
fresh user account, with the same results.

Aside: Running ```qdbus6 org.kde.KWin /KWin showDebugConsole``` with the
Clipboard tab open visualizes what is going on well (and, by merrit of slowing
down my system, possibly makes the issue occur consistently).

Occasional symptom: ```spectacle[41838]: Failed to send all clipobard data;
sent -1 bytes out of 939987```

Here are the reasons:
1) By disabling plasmashell's klipper (which you do in the System Tray settings
by setting the Clipboard icon to "Never (disable)") and using
https://github.com/Linus789/wl-clip-persist (which works for my use case), the
issue is gone.
2) Other native QT applications (kolourpaint, krita) have the same issue of the
clipboard contents disappearing after they are closed. (Krita was tested as the
prealpha appimage, with wayland QPA, bundeled QT 6.8, using "Copy merged"
instead of the regular Copy)
3) GTK applications (firefox, gnome "drawing") are fine, flatpak or no.
4) QT applications inside flatpak are FINE (presumably because they use the
desktop portal to hand over the clipboard data).

I don't really have a solid enough understanding of wayland/kwin/plasma to pin
down where exactly things go wrong, so I'd appreciate it if somebody could take
over the task of figuring that out and making a comprehensive report at the
right place! Feel free to link this comment.

As another tangent, I don't really understand what exactly is going in with
regard to the image formats in the clipboard. The KWin debug console makes it
seem like images are converted into 20 different formats, possibly lazily, and
the debug console itself is what triggers the actual conversion to occur? I'm
also reasonably sure that image data is being transfered and stored completely
uncompressed, which breaks down rather splendidly when you go to image sizes of
30000*3000 (long hangs, presumably over pipe communication, clipboard manager
taking over a GB of memory), but that may be a wayland protocol issue, IDK.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to