Bug 305781 - Option "Suspend desktop effects for fullscreen windows" makes the image freeze when going fullscreen in applications
Summary: Option "Suspend desktop effects for fullscreen windows" makes the image freez...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: compositing (show other bugs)
Version: 4.9.0
Platform: unspecified Linux
: NOR normal
Target Milestone: 4.10.2
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-25 20:34 UTC by Simonas
Modified: 2013-04-10 13:26 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.10.2


Attachments
dynamic blocking for definable FS windows (1.83 KB, application/octet-stream)
2013-01-29 18:47 UTC, Thomas Lübking
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Simonas 2012-08-25 20:34:48 UTC
Whenever i enable that option, open program e.g. dosbox, press Alt + Enter to go fullscreen then the video is frozen, and i see the last image which was before going fullscreen, altough i can interact with application and hear sounds and other stuff, but the video is frozen. When i uncheck this option, behaviour goes as normal.
Using nvidia 302.17, and kwin compiled from git master few weeks ago.

Reproducible: Always

Steps to Reproduce:
1.See details
2.
3.
Actual Results:  
Video is frozen

Expected Results:  
Shouldnt be that way
Comment 1 Martin Flöser 2012-08-25 20:40:57 UTC
I'm very close to drop the unredirection code...
Comment 2 Martin Flöser 2012-08-25 20:52:33 UTC
does that only happen with applications like dosbox or also with e.g. a normal video player? I want to no whether it is related to the application changing the resolution.
Comment 3 Thomas Lübking 2012-08-25 21:17:51 UTC
resolution changers...
Comment 4 Thomas Lübking 2012-08-25 21:25:35 UTC
also happens when setting a "ordinary" client fullscreen and then changing the resolution (through a timer)

However breaking fullscreen thus unredirection once and restore it after (ie. trigger and loose  popup, tooltip or whatever) will fix the stage.
Comment 5 Simonas 2012-08-25 22:53:11 UTC
yes, the problem happens only with resolution changers, whenever i go fullscreen with same resolution, it works just fine. im not sure either to drop this feature, actually with nvidia it always worked pretty nicely :)
Comment 6 Josep Febrer 2013-01-27 19:32:38 UTC
On my experience, this worked with KDE 4.8.4 on Debian sid with Intel graphics driver, but not since I upgraded to KDE 4.10 rc3, an the symptons are the same as described in this bug report, I can hear the sound, but the image freezes.
I also tested on another machine with an nVidia card, using the propietary drivers, on a Kubuntu system this feature worked fine on KDE 4.9 and also KDE 4.10 rc3.

Using the Bespin widget style, it has an option that works wonderfully for me, it's called "Suspend KWin compositing for SMplayer, VLC, DragonPlayer in fullscreen mode", to me it solved my video tearing issues when playing hd videos. It looks like this option is hardcoded, but in the Bespin way I don't have any trouble.
Comment 7 Thomas Lübking 2013-01-27 20:30:53 UTC
Bespin advises KWin to block compositing (dynamically when entering fullscreen - i propsed that to smplayer devs but they did not respond *shrug*)
There may be better chances with a regular NETWM flag for this.

For other applications you can either setup a rule (so that whenever a matching window shows up the compositor suspends - completely!) or probably use a script (but it's actually best set from within the client since it has pre-knowledge about eg. when it will enter fullscreen mode)

Sidenote: vdpau or xv should rather not alter the resolution (iirc neither should GL) - do you playback on the SDL or even X11 video output? (The latter is a major performance killer)
Comment 8 Josep Febrer 2013-01-27 22:32:51 UTC
You are right, the video playback do not alter the screen resolution, but that let me to do a little experiment, I edited Bespin's init.cpp and changed smplayer for frozen-bubble and dragonplayer from chromium-bsu, two of the games that changes screen resolution when goes to fullscreen and didn't work with KWin's "Suspend desktop effects for fullscreen windows", and rebuild Bespin.
These two games worked well with the Bespin's way, even after they changed the screen resolution on fullscreen.

So the way Kwin and Bespin suspend compositing it's different, to me, it worked more relliabily the Bespin way.
Thomas do you know if it's possible to use the Bespin way for all fullscreen applications?

I know that I can make rules, but I haven't found a way to create a rule for an application to suspend compositing only when it's in fullscreen. I created a rule for XBMC which also solves video tearing issues, but when I switch XBMC to window mode, the composition it's still blocked, although on XBMC that's irrellevant.
Comment 9 Thomas Lübking 2013-01-27 23:38:19 UTC
(In reply to comment #8)
> You are right, the video playback do not alter the screen resolution, but
> that let me to do a little experiment, I edited Bespin's init.cpp and
> changed smplayer for frozen-bubble and dragonplayer from chromium-bsu, 

Where did you find Qt variants of frozen-bubble and even chromium-bsu?

> So the way Kwin and Bespin suspend compositing it's different, to me, it
> worked more relliabily the Bespin way.

There's no way bespin suspends compositing.
The kwin setting refers to sth. called "unredirection" what means that compositing is actually fully active, but only this one (fullscreen) window is ignored by the compositor and its output is directed directly on screen.

Because this works less then ideal with several drivers, esp. if you use GL compositing and an OpenGL fullscreen window, and to provide even more resources, we added the ability for clients to block compositing, what is in a way like automatically pressing Shift+Alt+F12 (sth. that will always work - unless a window has grabbed all input. Some games do so, so it's necessary to suspend compositing before running them)

Despite the GUI calls both "suspend" (to not confuse the user, hah!) they're entirely different things.
The moment you suspend compositing the Shift+Alt+F12 (or Bespin, if you want) way, KWin is just a WM like in KDE3 times. All fancyness, shadows, translucency etc. is gone.


> Thomas do you know if it's possible to use the Bespin way for all fullscreen
> applications?
All Qt applications, yes - could be done by a wordlist matching the appName.
Dropping bespin  - a script, i assume.
One would hook onto the clientFullScreenSet(KWin::Client *client, bool fullScreen, bool user) signal, check the clients class and conditionally toggle useCompositing.

I'll try to write a sample script tomorrow (so you only have to bring your client list)
 
> I know that I can make rules, but I haven't found a way to create a rule for
> an application to suspend compositing only when it's in fullscreen.
Not possible. Rules are static ways to override certain window atteibutes because "i know better"
Comment 10 Josep Febrer 2013-01-28 00:18:20 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > You are right, the video playback do not alter the screen resolution, but
> > that let me to do a little experiment, I edited Bespin's init.cpp and
> > changed smplayer for frozen-bubble and dragonplayer from chromium-bsu, 
> 
> Where did you find Qt variants of frozen-bubble and even chromium-bsu?

Sorry, that was my confusion I wasn't aware that it only worked for Qt apps, so those games played with the normal composition enabled, and I didn't notice :)

> > So the way Kwin and Bespin suspend compositing it's different, to me, it
> > worked more relliabily the Bespin way.
> 
> There's no way bespin suspends compositing.
> The kwin setting refers to sth. called "unredirection" what means that
> compositing is actually fully active, but only this one (fullscreen) window
> is ignored by the compositor and its output is directed directly on screen.
> 
> Because this works less then ideal with several drivers, esp. if you use GL
> compositing and an OpenGL fullscreen window, and to provide even more
> resources, we added the ability for clients to block compositing, what is in
> a way like automatically pressing Shift+Alt+F12 (sth. that will always work
> - unless a window has grabbed all input. Some games do so, so it's necessary
> to suspend compositing before running them)
> 
> Despite the GUI calls both "suspend" (to not confuse the user, hah!) they're
> entirely different things.
> The moment you suspend compositing the Shift+Alt+F12 (or Bespin, if you
> want) way, KWin is just a WM like in KDE3 times. All fancyness, shadows,
> translucency etc. is gone.

Thank you Thomas for your explanation, that clarified a lot to me.
I used that shortcut since unredirection didn't work for me and it's really valuable to have that option. To my knowledge KWin is the only window manager capable of working with or without composite and enable or disable it on the fly, and one if it's best strengths in my opinion.
Comment 11 Thomas Lübking 2013-01-29 18:47:39 UTC
Created attachment 76788 [details]
dynamic blocking for definable FS windows

Bleh - kde-look doesn't talk to me :-(

Attached is a demo script, edit the list in ~/.kde/share/apps/kwin/scripts/gamemode/contents/code/main.js to your demands
Comment 12 Josep Febrer 2013-01-29 23:52:58 UTC
Your script is amazing, I think it should be included upstream, it can improve a lot hd video performance and avoid tearing and also for gaming. I love it.
And also it works for non Qt apps :)
Comment 13 Alexander Mezin 2013-03-20 04:55:03 UTC
I think I have proper solution for this problem:
https://git.reviewboard.kde.org/r/109597/
Comment 14 Martin Flöser 2013-03-22 10:34:55 UTC
Git commit d724bada226922794d341e97b334d1bbe696df82 by Martin Gräßlin, on behalf of Alexander Mezin.
Committed on 20/03/2013 at 07:10.
Pushed by graesslin into branch 'KDE/4.10'.

Fix unredirected windows not redrawn after display resolution change

REVIEW: 109597
FIXED-IN: 4.10.2

M  +3    -0    kwin/geometry.cpp

http://commits.kde.org/kde-workspace/d724bada226922794d341e97b334d1bbe696df82
Comment 15 Wolfgang Bauer 2013-04-10 13:26:01 UTC
I was suffering from this problem since 4.9 (didn't occur every time when switching the resolution).
It seems to be fixed now, it didn't happen anymore for me since updating to 4.10.2...

Thank you!