KWin Now Supports Suspended Compositing
KDE's KWin compositing window manager now supports suspended compositing that can be toggled by applications to provide a cleaner solution for stopping for removing the OpenGL context created by the KDE window manager and blocking the effects system so that directed full-screen applications and games should work better, especially with less than stellar graphics drivers.
KWin/KDE has already supported un-redirecting of full-screen windows in a composited environment, but up to this point the OpenGL context from KWin has still been maintained as well as the window manager's effects system. Thus while the performance may be improved in some instances (for the drivers that are faster without compositing), for other configurations this can still be an issue due to multiple OpenGL contexts and the resources of the effects system running.
With the latest code changes to KWin, proper suspending of compositing is now supported. Under this new model, the OpenGL context from KWin is removed and the effects system is shutdown. This suspending can be done via D-Bus or via Alt + Shift + F12 within KDE. If disabling KWin's compositing, it's also now using this suspended code path. That's if you wish to suspend KWin's compositing manually, but now there's a new way for applications to suspend the compositing automatically.
Not all full-screen applications should suspend compositing, such as when running a web-browser full-screen, but in this case of playing back videos full-screen or a game, KWin compositing can be safely suspended. When an application tells KWin to suspend compositing, it's blocked (with the effects system suspend and OpenGL context removed) until no application is requesting this change of state.
Martin Gräßlin is hoping multi-media applications, games, and Wine will implement support for this suspend-compositing call. The KDE developers are also hoping to make this part of the NETWM specification.
Martin is hoping that the user-interface for toggling compositing can be removed in KDE SC 4.8 as manually changing states will no longer be needed. Though GNOME 3.0 and Ubuntu's Unity desktop wouldn't support this same functionality quite as well since both desktops have an explicit requirement of compositing.
Read more in this blog post.
KWin/KDE has already supported un-redirecting of full-screen windows in a composited environment, but up to this point the OpenGL context from KWin has still been maintained as well as the window manager's effects system. Thus while the performance may be improved in some instances (for the drivers that are faster without compositing), for other configurations this can still be an issue due to multiple OpenGL contexts and the resources of the effects system running.
With the latest code changes to KWin, proper suspending of compositing is now supported. Under this new model, the OpenGL context from KWin is removed and the effects system is shutdown. This suspending can be done via D-Bus or via Alt + Shift + F12 within KDE. If disabling KWin's compositing, it's also now using this suspended code path. That's if you wish to suspend KWin's compositing manually, but now there's a new way for applications to suspend the compositing automatically.
Not all full-screen applications should suspend compositing, such as when running a web-browser full-screen, but in this case of playing back videos full-screen or a game, KWin compositing can be safely suspended. When an application tells KWin to suspend compositing, it's blocked (with the effects system suspend and OpenGL context removed) until no application is requesting this change of state.
Martin Gräßlin is hoping multi-media applications, games, and Wine will implement support for this suspend-compositing call. The KDE developers are also hoping to make this part of the NETWM specification.
Martin is hoping that the user-interface for toggling compositing can be removed in KDE SC 4.8 as manually changing states will no longer be needed. Though GNOME 3.0 and Ubuntu's Unity desktop wouldn't support this same functionality quite as well since both desktops have an explicit requirement of compositing.
Read more in this blog post.
69 Comments