>investigate weird amount of "application not responsive" incidents on a prod app
>makes no sense since we haven't deployed anything
>waste days over days debugging, can't reproduce it
>turns out KDE made wayland default recently and for whatever the frick reason, swapbuffers call is blocked on wayland clients when the window is not visible
>without even any callback indicating it
Who the frick made those decisions?
>Who the frick made those decisions?
Infosec nerds, aka followers of Satan.
>using KDE
wayland is deliberate sabotage
It really is. Plasma 5.27.10 was so good i thought it's finally The Year, then Nvidia 550 driver made it MUCH better (whoever is on nvidia won't let me lie). And then, a couple of days later Plasma 6 shits on everything.
I am baffled.
>whoever is on nvidia won't let me lie
Can confirm. Was sitting on 5.15 for awhile because of a screen flicker bug (that was still around on 5.35)
5.50 feels really nice and no issues.
almost like wayland is an inside job meant to kneecap the linux desktop
Wayland is not ready. Plasma 5 worked like a dream for me, Plasma 6 has been a disaster. I have a 4000 series Nvidia card, like most gamers. If your shit doesn't work on 80% of the hardware by marketshare, it's not ready.
Wayland is a humiliation ritual. It will never be ready.
It's really funny that they mull over protocols and "the right way to do things" forever and still frick up.
These are Qt bugs. KDE can restore clients even if the WAYLAND_DISPLAY disconnects. You can kill its entire compositor and it'll restart anew, in theory with nothing breaking should clients be well behaved.
In fact, Qt even tries to re-connect but it doesn't work right anyway:
$ kolourpaint
^Z
[1] + 8403 suspended kolourpaint
$ fg
[1] + 8403 continued kolourpaint
The Wayland connection broke. Did the Wayland compositor die?
qt.qpa.wayland: Attempting wayland reconnect
Failed to write to the pipe: Bad file descriptor.
qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
[1] + 8403 segmentation fault kolourpaint
So it does actually attempt to re-connect yet that fails for some reason. Maybe there is a mismatch somewhere between the state in the compositor and the state in the client.
>These are Qt bugs.
Wrong.
Also Qt6 is the only framework that even tries to cope with this protocol bug.
GTK doesn't give a shit. KDE had experimental patches for attempting to deal with it but they don't want it and even made it clear that they think it's a bad idea and that their applications should just crash instead.
what makes you think crashing apps is a bad idea metric?
>sir you can't block in gui thread
>siiiiiiiiiiir
Holy shit that fricking protocol is so invasive. No way it isn't designed to destroy OSS altogether.
Its you fault
Why the frick does your entire app lock up when the render thread is blocked?
struct wl_ring_buffer {
char data[4096];
}
you don't NEED more than 4096 bytes chuddie
What sort of world do they think we live in, where 4k is the size of ring buffer?
We don't have 640k of RAM any more. There's no need for it to be so tiny.
At least make it mean something, like 64k.
>64k
>bloat
Do you write your compositor in electron anon
Because any other platform literally informs the app about it, while wayland just silently blocks it and blames you for not having it in a thread
>Who the frick made those decisions?
Mentally ill security theater cultists
In 3 days you guys will be praising gayland in another thread
>shills exist, therefore everyone on IQfy is the same person
updooters gonna updoot. their shit will break and they will always blame someone/something else. protip: don't promise support for updooter distros that can and will frick you over at any moment.
>swapbuffers call is blocked on wayland clients when the window is not visible
>without even any callback indicating it
Just create a new thread and check every 5 seconds whether the GUI thread is responding.
>inb4 that's ugly!
it's what you get when you program for the ugly and ad hoc hacked together piece of shit OS known as Linux. you thought microsoft and backwards compatibility was messy? LMAO
using a gui process for background tasks in the first place is ugly, wayland is just exposing the shitty design of OP's application
>N-NO YOUR APP HAS TO USE MULTITHREADING NO MATTER WHAT IT IS USED FOR
Why did they decide to break everything? What was the agenda?
Wayland is written by troons working for the NSA, don't be surprised at this. It's not designed to work properly.
X11 was designed to run on very slow computers. As a result, it has a better threading/concurrency model.
Wayland is simply too demanding.
It's a shame though, because presentation in wayland can be really good when it isn't shitting the bed.