Every release has a killer feature. Qt 6.6 features the opposite - staying alive. This blog post describes work to make Qt clients more robust and seemlessly migrate between compositors, providing resistance against compositor crashes and more.
- Checkpoint restore in userspace, being able to suspend your application to disk and then pick up where you left off like nothing happened. It could never work for X applications, but with wayland reconnect support we can make it work.
This would be great for Plasma Mobile and decrease the energy consumption by a lot.
Energy consumption for sure, but also handling multitasking in memory-constrained situations would be a boon here too. The system could make checkpoints and kill apps not visible on screen when RAM is at a premium. It could also make checkpoints when the battery is at a certain % before a forced shutdown occurs.
Silly question time, because why not: Could Activities be revamped via checkpoints?
Activities become Wayland-only in P6. Kwin transitions would need updating?The article talks about OpenGL applications being able to be restored if they handle GPU resets. Does this also work for for Vulkan apps? AFAIK Vulkan has its own way of interfacing with display servers (ie. not EGL).
You should edit the wiki on criu.org to talk about Checkpoint/Restore of graphical apps with Wayland. Or at least you should plan to do so when more toolkits support it.
Just wondering about how CRIU in GUI would actually work out in practice. What would happen if say, for example, a game’s state is suspended and resumed on another computer with a different GPU vendor?
I just realized: with checkpoint restore, would the “Stop activity” button be able to completely store an Activity to disk, leaving it without using CPU or RAM, and be restored as it was before for all apps? Could we maybe even make this the default behavior when switching Activities, so it by default always consumes less resources than the simple Activity switching that we currently have?
From what I recall (it’s been a while that I haven’t set up Activities here so I might be wrong), just switching between Activities does not stop apps from using RAM and CPU, stopping an Activity is what does that (only for apps that have support for session restore I believe).
@David_Edmundson could you please share the app you use to switch between compositors?
If I understand correctly this would me allow to switch between plasma 5 session and plasma 6 session?
As @Herzenschein mentioned, “stoping” an activity is something that can benefit from checkpoint/restore as you’ll be able to stop an activity with applications running in it and then when you start it again - possibly many reboots later - everything will continue running.
But for day to day to usage, unless checkpointing and restoring is almost instantaneous, I wouldn’t want that - and probably not even then: I often switch from one activity to another leaving a long running task to complete while I switch context for a while to game or read while the work stuff takes care of itself in the background.
@David_Edmundson the KDE Wiki links to Mesa patches to enable this more widely, are is there a corresponding MR on the Mesa Gitlab itself so this can make it upstream ?
I don’t know if this is related to the Wayland robustness work, but I just had an issue with kwin_wayland on Plasma 6.0 beta 2 - my screen froze and I had to kill -9 kwin_wayland, and my session recovered! I was very much pleasantly surprised.
Some applications crashed, but my Konsole instance remained - which was the important part.
All Qt 6.6 application should survive a kwin crash, I think.
That’s correct. And other apps that opt into the feature too; IIRC Firefox is working on it, and I think patches have been submitted for GTK4 and SDL too.