Among the Firefox Wayland bugs, one of the top crash bugs is over a lost connection to a Wayland compositor. For dealing with it is to have a proxy between Firefox and the Wayland compositor to cache messages and prevent compositor message queue overflows.
BeOS solved the issue of unresponsive GUIs in the 1990s. The GUI just must never run in the same thread as the logic.
while this is good on theory, when your CPU is being absolutely hammered, you need to re-adjust priorities to make a system responsive again, it’s actually not a simple thing to do without a context aware scheduler. Even though EEVDF is pretty good, it still struggles some times
My PC with a 133MHz Pentium 1 processor was pretty responsive all the time back in the day. It’s definitely a solved problem.
I agree. The proxy solution they’re proposing seems like a band-aid on a fundamental design issue to me. It’s easier to just tack yet another library onto a big project than to refactor large amounts of code. This is exactly why a lot of software is getting more and more shit.
Also this is the kind of issues Wayland will be facing now that it’s starting to see widespread adoption, issues that arise from more and more complex situations created by interconnecting more apps with it in more ways.
How the devs handle this will be crucial and imo it can make or break the project in the long run. It’s one thing to successfully run a hobby project at a small scale, it’s another to shoulder the entire Linux desktop for the foreseeable future. That’s the bar that X had to meet; if Wayland intends to be the Linux desktop it has to step up. “Not our problem, deal with it outside Wayland” will not do.