Version: unspecified (using KDE 4.4.3) OS: Linux The summary pretty much says it all. I think the best way to implement this would be through a boolean switch in the program's .desktop file. KWin could receive the calls to suspend (and resume when the game exits) via D-Bus. The need for this functionality is illustrated in this article: http://www.phoronix.com/scan.php?page=article&item=kwin_speed_test Reproducible: Always Steps to Reproduce: Run a game with desktop effects enabled, then disabled, observing the FPS each time. Actual Results: FPS will almost invariably be lower with desktop effects enabled. Expected Results: Same. If KWin did what's requested in this feature request, there would be no major performance hit on openGL apps, and users would still have the functionality of a modern window manager.
kwin unredirects fullscreen windows unless you (or your distro) disabled that feature. "kreadconfig --file kwinrc --group Compositing --key UnredirectFullscreen" should be "true". actually you can use dbus to toggle compositing, but you probably want to use shift+alt+f12. having processes automatically un/block compositing is problematic. two processes might interfer (one exits and resumes compositing, while another one still wants it turned off) so actually kwin would require a counter on block requests and if one of those processes ever segfaults (or fails in other ways) you'd end up with "unresumable" compositing. a simple bash approach using dbus: #!/bin/bash was_composited=$(qdbus org.kde.kwin /KWin compositingActive) if $was_composited; then qdbus org.kde.kwin /KWin toggleCompositing fi quake # don't fork! is_composited=$(qdbus org.kde.kwin /KWin compositingActive) if $was_composited != $is_composited; then qdbus org.kde.kwin /KWin toggleCompositing fi ## ---------------------------------- end sidenote: please do not make up your opinion about anything base upon phoronix "benchmarks". esp this one (one observation is that compositing "boosts" the catalyst driver for some games...) is ridiculous - these guys do clearly not have a slight idea of what they're doing (and this is not only about this test. it's the very same story everytime) - the environment is not clean. they test on a running KDE desktop [and btw. compare it to a running gnome desktop, maybe fetching some torrents meanwhile...] what means that a dozen daemons hang around. supporting this, some tests are clearly cpu limited. this means that their test environment is not free of side effects, the benchmarks could be influenced by strigi starting to update the database or whatever. - there's no hint about the precise configuration of the test target (the window manager), eg. the above key for kwin or the active plugins - there's no hint about the configuration of the test item (do the games run in real fullscreen mode or a borderless maximzed window) they just somehow fire their "testsuite" on something under some conditions and on some hardware to show some results that say something. the important word here is "some". there's no reflection. if you notice that sth. that's supposed to take away HW resources ends up improving your test results, you should really start to wonder what might be wrong with your test, sorry. also for the rant.
*** This bug has been marked as a duplicate of bug 198744 ***