Bug 177495 (unredirect-flicker) - Fullscreen windows unusable due to heavy flickering
Summary: Fullscreen windows unusable due to heavy flickering
Status: RESOLVED FIXED
Alias: unredirect-flicker
Product: kwin
Classification: Plasma
Component: compositing (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 179859 180767 184002 184020 185067 191082 194872 201148 201777 206360 208948 209096 209868 217750 220210 224939 225231 247656 255975 258611 278024 292462 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-12-11 15:38 UTC by Giovanni Masucci
Modified: 2012-09-19 12:49 UTC (History)
47 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Package manager's log file before the flickering started (5.88 KB, text/plain)
2009-03-02 22:41 UTC, Jörg Bäuerle
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Giovanni Masucci 2008-12-11 15:38:57 UTC
Version:            (using Devel)
OS:                Linux
Installed from:    Compiled sources

hello, I on kde 4.1.82 using an intel card.
With desktop effects ON I get an heavy flickering in fullscreen windows that make a real pain using apps in fullscreen (link web browsers full screen mode), especially if you do a right click to open a menu. This is happening since unredirect full screen windows has been introduced in kwin, during kde 4.2 cycle. Infact 4.1 works fine (not sure about opensuse version, since there are many backports from 4.2).
If there's no possible fix for this other than wait for a better intel driver version I would say an option to disable this new behaviour is really needed. Fullscreen windows are very important in netbooks where the screen space is very limited.
Comment 1 Martin Flöser 2008-12-11 15:53:17 UTC
I don't think it is related to drivers as I am experiencing the same behaviour with nVidia.
Comment 2 Martin Flöser 2008-12-11 17:38:26 UTC
If we don't find a solution for it than we should set UnredirectFullscreen to false by default. I think the flickering is worse than the problems with videos or OpenGL application and for these cases we have the shortcut to suspend compositing.

You can disable unredirecting the following way:
1. open ~/.kde/share/config/kwinrc in an editor
2. go to section [Compositing]
3. Add following line:
UnredirectFullscreen=false
4. Save file and restart kwin (alt+f2 and kwin --replace)
Comment 3 Giovanni Masucci 2008-12-12 20:21:15 UTC
I just want to add that most graphic cards shouldn't have problems anymore with latest drivers regarding videos... (for example intel switched to exa+ textured video, which is ok with composite). nvidia should be ok with opengl apps too. Intel and ati should (hopefully) work fine too as xserver 1.6 gets released in 01/2009 with dri2 support...so if we are lucky, when 4.2 gets out, unredirect full screen could be not so important anymore...fingers crossed =)
Comment 4 Martin Flöser 2009-01-07 12:02:48 UTC
*** Bug 179859 has been marked as a duplicate of this bug. ***
Comment 5 Martin Flöser 2009-02-11 14:19:57 UTC
*** Bug 184020 has been marked as a duplicate of this bug. ***
Comment 6 Martin Flöser 2009-02-24 10:29:02 UTC
*** Bug 185067 has been marked as a duplicate of this bug. ***
Comment 7 Jörg Bäuerle 2009-03-02 22:41:49 UTC
Created attachment 31744 [details]
Package manager's log file before the flickering started
Comment 8 Jörg Bäuerle 2009-03-02 22:43:07 UTC
Erm, yeah that didn't work like expected...

Read this comment first and then check attachment above. ^^

I'm using a NVidia Quadro NVS 110M and I'm experiencing the same under KDE 4.2. As I'm using Arch Linux I should have the latest bleeding edge KDE stuff.

I don't know whether it is related to direct rendering though, as it happens regardless of the OpenGl Options in my KDE settings dialog.

It seems especially bad if I have a plasma panel on "auto hide", but I can't really nail it.

The whole problem only started yesterday for me when i did a full system update and my package manager upgraded a whole bunch of KDE stuff.

See attachment for the updated packages.
Comment 9 Jörg Bäuerle 2009-03-02 22:53:13 UTC
Hm, could also be related to this bug: https://bugs.kde.org/show_bug.cgi?id=184002
Comment 10 lucas 2009-03-03 03:23:40 UTC
*** Bug 184002 has been marked as a duplicate of this bug. ***
Comment 11 Hans Meine 2009-03-19 16:10:44 UTC
Happens here, too, with x11-drivers/nvidia-drivers-180.22 on Gentoo.
Comment 12 Martin Flöser 2009-04-30 10:18:17 UTC
*** Bug 191082 has been marked as a duplicate of this bug. ***
Comment 13 Martin Flöser 2009-06-01 15:32:03 UTC
*** Bug 194872 has been marked as a duplicate of this bug. ***
Comment 14 Konstantin 2009-06-01 20:59:16 UTC
Confirm that.
Screen is flashing in KDE ver. 4.2.88svn973768
OS: openSUSE 11.1
Video: NVIDIA GF 8400GS
Driver: nvidia proprietary ver. 180.51
Comment 15 Sergio PR 2009-06-04 10:35:10 UTC
Same problem here.
Debian SID
KDE 4.2.4
nVidia drivers: I tried 180.60 and 185.18.14
Comment 16 Fernandel 2009-07-10 15:36:37 UTC
Solution from comment #2 does not work here.
KDE 4.2.4
Latest Intel drivers from Git.
Kwin desktop effects activated.
Everything else works perfectly with these drivers: games, video,...
I had to disable desktop effects.
Comment 17 Thomas Lübking 2009-07-10 15:55:11 UTC
it's not like "~/.kde4/..." for you, is it?
Comment 18 Ivo Anjo 2009-07-10 19:54:43 UTC
I'm no kwin/X developer, but my understanding is that with the current X DRI/AIGLX architecture, when 3d effects are enabled, any window gets redirected first through the window manager/compositor (that's what AIGLX stands for: accelerated _indirect_ glx). This redirection comes at a (small-ish) performance hit.

As a quick performance "hack", kwin doesn't redirect single fullscreen windows (like games), so you'll have full performance with a single fullscreen window. The problem is, when a fullscreen window like firefox opens a menu, there are now two windows, and the flicker you see is the fullscreen window being redirected when the menu opens, and unredirected again when it closes.

I think the only real solution for this might be with drivers supporting DRI2, where you can have accelerated direct glx / direct rendering, which should get you full speed even when running with 3d effects.

In the meantime, it would be nice if you could have "don't unredirect this window if fullscreen" as a window-specific setting: this way you could have the best of both worlds, unredirected fullscreen for games and such, and for firefox and others you could disable it just for that application.
Comment 19 Martin Flöser 2009-07-10 20:10:10 UTC
(In reply to comment #18)
> In the meantime, it would be nice if you could have "don't unredirect this
> window if fullscreen" as a window-specific setting: this way you could have the
> best of both worlds, unredirected fullscreen for games and such, and for
> firefox and others you could disable it just for that application.
I don't think it's worth the effort. It could be included at earliest in 4.4 and at that time - or better said when it is included in distros - DRI 2 support should be available for all drivers (hopefully).
Comment 20 Ivo Anjo 2009-07-10 20:19:53 UTC
(In reply to comment #19)
> I don't think it's worth the effort. It could be included at earliest in 4.4
> and at that time - or better said when it is included in distros - DRI 2
> support should be available for all drivers (hopefully).

I hope you are right, but the track record with nvidia and amd proprietary drivers has not been that good, I think 'we' would be lucky if one of them supports DRI2 by the end of next /year/ :|
Comment 21 Fernandel 2009-07-13 18:23:18 UTC
Thank you Thomas Lübking for comment #17 ! Now Kwin works perfectly with Firefox in full screen mode!
I had modified ~/.kde4 instead of ~/.kde
I believed ~/.kde was deprecated since I use KDE 4.2.4 in Debian. I wonder why the two survive in the home directory (for KDE 3.5 software?). I think this is confusing and can lead to mistakes, like people deleting ~/.kde
I agree with the comment saying that believing DRI2 will be implemented before the fix can be programmed is a bit optimistic.
And what about people who use old drivers, or companies not updating drivers for old chips?
Comment 22 Jason 'vanRijn' Kasper 2009-07-17 03:22:37 UTC
Just wanted to note that this also affects VMware Workstation and Player in the same way. Going fullscreen is fine, but hovering over any of our fullscreen toolbar buttons (which causes a tooltip to come up) causes incessant flickering of the main app. Also, switching back and forth between monitors in a multimon setup can cause the monitors to stop refreshing and displaying the correct window contents. Adding UnredirectFullscreen=false to the Compositing section of kwinrc fixes the problem nicely. =:) Note that Compiz has the same problem, but it has a checkbox for disabling "Unredirect fullscreen windows", so it's a little bit easier for users to affect the change. This might be something nice to add to the advanced desktop settings page.
Comment 23 Martin Flöser 2009-07-22 21:58:35 UTC
*** Bug 201148 has been marked as a duplicate of this bug. ***
Comment 24 Thomas Lübking 2009-07-29 14:55:04 UTC
*** Bug 201777 has been marked as a duplicate of this bug. ***
Comment 25 Konstantin 2009-07-29 20:38:51 UTC
Do you remember all those funny tweakers for Windows allowing one to play with hidden settings of his/her system?
Maybe it's time to write something like this for KDE :)
Does anyone know about other undocumented KDE4 settings?
Comment 26 Giuseppe Bilotta 2009-08-06 21:57:01 UTC
I'm also exepriencing this issue on KDE 4.3.0 with compositing enabled, using the latest CUDA-enabled nvidia binary drivers (190.x). Unredirecting fullscreen as suggested in comment #2 solved the issue for me.

May I suggest the option be the default in future versions of KDE? ;-)
Comment 27 Ivo Anjo 2009-08-06 23:25:15 UTC
(In reply to comment #26)
> May I suggest the option be the default in future versions of KDE? ;-)

I don't think that's such a good idea, because with compositing ON being the default on KDE it means most users will instantly lose performance on games and other 3d apps (and we have few linux gamers as it is).

I think having it as a window/app specific setting is the way to go. Extra points if by default a small blacklist is included, listing things like konqueror, arora, firefox, gwenview and other apps that might suffer from this, and that don't really need the unredirect.

Another option is if kwin notices that it is redirecting/unredirecting a lot of times some window, it prompts the user something like:

The current fullscreen application seems to be having trouble with desktop effects. What do you want to do?
[ Enable compatibility mode ] [ Ignore ] [ Turn off desktop effects ]
[ ] Remember my choice for this application

Compatibility mode being disabling unredirect, but users don't need to know that lingo, they only need to know "clicky this buttony, and flickery goes awayie".
Comment 28 Nicolas Bigaouette 2009-08-15 18:56:06 UTC
I want to add that without the UnredirectFullscreen=false flag, I cannot access my autohiding panel when chromium is focused. 

Chromium's window borders are also appearing without the flag.

When setting the flag to false, Chromium behave exactly as supposed (window borders disapear since its a fullscreen app, autohinding panel re-appear when mouse over). There is also no flickering anymore.

I whish that flag had an option in the config dialog, or at least a popup when the first flickering happens. A per-application/per-window setting might be overkill: I don't run linux for games, so I'm more willing to disable the flag if I ever want to run a game, instead of the opposite.
Comment 29 Bartek Iwaniec 2009-09-05 13:45:52 UTC
*** Bug 206360 has been marked as a duplicate of this bug. ***
Comment 30 Martin Flöser 2009-09-30 08:30:50 UTC
*** Bug 208948 has been marked as a duplicate of this bug. ***
Comment 31 Martin Flöser 2009-10-01 14:09:29 UTC
*** Bug 209096 has been marked as a duplicate of this bug. ***
Comment 32 Martin Flöser 2009-10-08 14:26:58 UTC
*** Bug 209868 has been marked as a duplicate of this bug. ***
Comment 33 Ken Rushia 2009-10-08 22:00:18 UTC
Does this bug include instances where the entire screen flickers off and may cause the monitor/card to turn off?
Comment 34 Thomas Lübking 2009-10-08 22:12:40 UTC
(In reply to comment #33)
> Does this bug include instances where the entire screen flickers off and may
> cause the monitor/card to turn off?

Rather not, this is about windows taking a full (and visible) unmap/map cycle when they temporarily use their fullscreen status (e.g. because a popup appears), see esp. comment #2

A periodical flicker (not triggered by a permanent fulscreen state toggle) that also turns off your monitor (triggers dpms?) sounds rather like a driver bug or a broken GPU..

So the question is: why does the flicker occur for you?
Comment 35 Pete Miller 2009-10-14 03:53:10 UTC
Bug 180767 looks like another duplicate of this one.
Comment 36 Martin Flöser 2009-10-14 08:23:26 UTC
*** Bug 180767 has been marked as a duplicate of this bug. ***
Comment 37 Cédric Bellegarde 2009-10-25 17:12:39 UTC
I'm using UnredirectFullscreen=false and i have no problem playing openarena... No performance problem ...

I prefer UnredirectFullscreen=false by default and a hack for games...

Isn't possible for kwin to check if a window use openGL and enable Unredirect if this window go fullscreen?
Comment 38 Martin Flöser 2009-12-07 19:24:32 UTC
*** Bug 217750 has been marked as a duplicate of this bug. ***
Comment 39 Martin Flöser 2009-12-27 10:48:28 UTC
*** Bug 220210 has been marked as a duplicate of this bug. ***
Comment 40 razi 2009-12-29 17:43:08 UTC
happen to mee to.
opensuse 11.2, kde 4.3 intel 965.
when hover down on fullscreen, screen flicker instead of showing seek bar.
Comment 41 Ben Morris 2010-01-11 00:50:35 UTC
Same issue here on a Radeon HD 3870 using open-source drivers. The workaround works fine.

KDE 4.3.4; kernel 2.6.33-rc2; recent xf86-video-ati from the Git repo.
Comment 42 Thomas Lübking 2010-01-31 00:33:29 UTC
*** Bug 224939 has been marked as a duplicate of this bug. ***
Comment 43 Victor Gavrish 2010-01-31 00:55:43 UTC
Could this setting be set by default for latest intel drivers? I believe they support DRI2 (and in fact don't support DRI1) so the performance problem shouldn't exist here.
Comment 44 Martin Flöser 2010-02-02 09:02:53 UTC
*** Bug 225231 has been marked as a duplicate of this bug. ***
Comment 45 Kamil Neczaj 2010-03-28 14:02:35 UTC
I have a proposision.

When a window is set fullscreen and  kwin would block showing on top all notifications and other windows that belongs to other applications. This is ideal behaviour when the user plays games. When I play Warcraft on Wine every notification is a bit annoying. This would solve the problem in games. 

There are also other programs working on fullscreen such as chrome, firefox, smplayer. These programs have menus, pop-up toolbars (smplayer) etc. which appear on top of the window and also causes fickering. When the new window appears and the window belongs to fullscreen window undirect rendering (compositing) is turning on and the window name is saved on "black list". Then if the window from "black list" become fullscreen again kwin will know that Undirect rendering shouldn't be turned off.

So again:
1. window becomes fullscreen -> Undirect rendering is turned off (default now)
2. windows not belonging to the fullscreen one appears (notifications etc) -> kwin doesn't show them on top -> Undirect rendering remains off.
3. window belonging to fullscreen window appears (menu, toolbar etc.) -> Undirect rendering is swiched on and the fullscreen window is saved to a black list -> now all notifications etc can appear on top of it (point 2)
4. window becomes fullscreen again -> look at blacklist whether if should be rendering undirect.
5. Some programs: firefox, gwenview, smplayer can put on black list by default.

This algorithm let the kwin learn how to threat fullscreen windows and probably have no drawbacks, but some work to make it ;)
Comment 46 Thomas Lübking 2010-03-28 18:50:03 UTC
(In reply to comment #45)
> I have a proposision.
Thank you for sharing your minds. I'm sure every idea is appreciated on this, but i fear it's not that simple :-(
 
> When a window is set fullscreen and  kwin would block showing on top all
> notifications and other windows that belongs to other applications. 

No.
1) "belongs to other applications" is heuristic. There's no definite connection between processes and windows.
2) Suppose you're using sth. like OOo in FS mode and it makes use of kdialog to open/save/print files for desktop integration -> you request to open a file but nothing shows up ever* ...

> notification is a bit annoying. This would solve the problem in games. 
This is a problem of notifications. They need a silent mode or simply check whether there's currently a fs window and hold window spamming back (though this would only fit gaming, not working on a fs app)

> There are also other programs working on fullscreen such as chrome, firefox,
> smplayer. These programs have menus, pop-up toolbars (smplayer) etc. which
> appear on top of the window and also causes fickering. When the new window
> appears and the window belongs to fullscreen window undirect rendering
> (compositing) is turning on and the window name is saved on "black list". Then
> if the window from "black list" become fullscreen again kwin will know that
> Undirect rendering shouldn't be turned off.

"Should not be unredirected again", i assume?

However, you do certainly _not_ want unredirecting blacklisted for a videoplayer just because you once opened a dialog/popup to eg. open a file.
Also you've the same problem about the weak window/process connection :-(

What probably should happen is a (short) delay before re-unredirecting, as usually old popups are unmapped before new ones are mapped.
This way one could at least avoid flickering when sliding across menubars.

* as the dialog does not "belong" to the app - well as long as it doesn't mark itself transient, what means we're looking for modals only... no normal dialogs and probably no popups etc.
Comment 47 Martin Flöser 2010-04-18 22:12:54 UTC
I noticed the problem also existis with XRender backend, so it is not OpenGL specific.
Comment 48 Venky 2010-04-19 03:30:28 UTC
I am on ati git drivers and 2.6.34 rc kernel using kde 4.4.2 SC even with dri2 I am experiencing flicker with fullscreen videos.
Comment 49 Ivo Anjo 2010-04-19 09:24:56 UTC
(In reply to comment #48)
> I am on ati git drivers and 2.6.34 rc kernel using kde 4.4.2 SC even with dri2
> I am experiencing flicker with fullscreen videos.

I have exactly the same issue, with latest stable ati drivers / Xorg, 2.6.34rc, and latest stable KDE.
Comment 50 Thomas Lübking 2010-04-19 12:27:43 UTC
@comments #48 & #49: do you rather mean "tearing"?
this bug is about flicker when an unredirected window is being redirected again, eg. because of a popup or a panel showing up.

@martin:
theoretically one can "freeze" the X11 server to prevent any kind of update (the empty moveresize does such) - but my attempts in this direction failed in this regard either :(
Comment 51 Marvin 2010-04-29 00:02:15 UTC
This annoying flickering bugs me for ages. Just found this bug entry and the setting mentioned in post #2 (UnredirectFullscreen=false) works for me like a charm! No more flickering while running xbmc, gwenview, flashplayer, vlc etc. I wonder why this is not the default. Can some explain why? But if there are no critical reasons against that setting, please do it by default. Every little restriction is always better than this flickering!

my system:
archlinux/kdemod
kde sc 4.4.2 with compositing
nvidia 195.26.15
xorg 7.5
x-server 1.7.6
Comment 52 Thomas Lübking 2010-04-29 00:18:38 UTC
performance, just read this thread (maybe try comment #18 first ;-)
Comment 53 Grósz Dániel 2010-04-29 00:31:18 UTC
#52: Doesn't this bug happen on every configuration with compositing? A bit of performance hit is better than unacceptable flickering (which makes it much more unusable) so in that case it would be better to make it default. Also if it does not happen everywhere but it is known to always happen with specific video cards/drivers, it would be possible to make UnredirectFullscreen=false default with those video cards.
Comment 54 Victor Gavrish 2010-04-29 00:45:02 UTC
I agree. I didn't even notice the performance hit, but the annoyance level has decreased substantially. Of course, it might have something to do with the Intel driver supporting DRI2, but I think most drivers support it nowadays.
Comment 55 Marvin 2010-04-29 00:55:50 UTC
are there any benchmarks which show, how much performance is lost when using UnredirectFullscreen=false?
Comment 56 Pete Miller 2010-04-29 01:07:03 UTC
When I try to run TVTime with UnredirectFullscreen set to false it causes a substantial increase in its CPU usage. This results in a very noticeable and unacceptable loss of frame rate. Maybe it's worth the performance hit on newer hardware, but unfortunately it is not on my system.
Comment 57 Victor Gavrish 2010-04-29 01:08:50 UTC
@#56: What video driver are you using?
Comment 58 Thomas Lübking 2010-04-29 01:13:25 UTC
this heavily depends on your gpu/driver and the fullscreen app.

try eg. nexuiz or sauerbraten (for opengl - any shooter with an fps counter/timedemo should do)

you could also play a video and monitor top for kwin and X11
(this can however not show the GPU overhead)

   top -b -p `pidof kwin`,`pidof X` | grep -E '(kwin|X)'

in general the texture_from_pixmap conversion is rather expensive and scales with the demanded framerate (thus 50/60Hz TV is critical, yes)

for "low update ratio" applications (text processors) it doesn't matter.
Comment 59 Thomas Lübking 2010-04-29 01:32:03 UTC
for the records:
it seems the redirected client paints the root pixmap until the feed is re-available (causing the flicker) so 

weird idea (tm)
it might help to place the last known window pixmap there before un-redirecting...
Comment 60 Pete Miller 2010-04-29 03:19:46 UTC
@57: I am using the binary Nvidia driver, version 185.18.36
Comment 61 Shaun Reich 2010-04-29 03:36:21 UTC
rm my cc..way too high traffic for me.
Comment 62 Victor Gavrish 2010-05-21 11:04:14 UTC
Phoronix has investigated the performance drop of Compiz, which I think should be the same as the performance drop of redirected windows, or at least tie into it very closely.

http://www.phoronix.com/scan.php?page=article&item=compiz_speed_test&num=1

"With the Intel Linux driver and open-source Radeon driver as found in Ubuntu 10.04 with other newer distributions using kernel mode-setting and DRI2, there is about a 15% performance hit taken when Compiz is running with just the standard desktop effects. There are some games where the performance hit is not as much, but other cases where it is more. However, the Radeon driver when using the older user-space mode-setting with DRI1 support was barely affected by Compiz and in general is faster than the KMS-DRI2 code-paths that still need to be better optimized.

AMD's binary driver -- the ATI Catalyst driver -- overall did the best where it was immune from any performance drops when using Compiz over Metacity. Only with the very demanding Unigine Heaven was there any measurable impact from using Compiz and that was just at 5% while the performance of NVIDIA's driver had changed in that same test by more than 60%.

Like the Intel and Radeon DRI2/KMS drivers, the proprietary NVIDIA driver was also prone to noticeably lower frame-rates when Compiz was enabled to provide basic desktop effects on Ubuntu. Fortunately the NVIDIA driver is much faster than the open-source ATI/Intel drivers and their hardware is also faster, so the NVIDIA Linux gamer isn't affected as much unless the configuration right now is just on the brink of being playable. Some of NVIDIA's performance losses when running Compiz may also be recovered if starting Compiz with the --loose-binding argument where Compiz textures are enabled when they are created, which works around an issue of some NVIDIA driver releases being slow at binding textures. Of course, if you are unsatisfied with the performance when running a full-screen game or program under Compiz, you can always temporarily stop it until your driver(s) have better optimized composite performance or Compiz is changed to do direct rendering when running a full-screen application."

The performance drop for Intel and AMD drivers is not very large, so I suggest that unredirecting fullscreen windows with this hardware be disabled by default. Also, if there is an option similar to --loose-bindings for kwin, I suggest it be turned on by default for NVIDIA hardware.

What do you think?
Comment 63 Martin Flöser 2010-05-21 18:07:57 UTC
> --- Comment #62 from Victor Gavrish <loonyphoenix gmail com>  2010-05-21
> 11:04:14 --- Phoronix has investigated the performance drop of Compiz,
> which I think should be the same as the performance drop of redirected
> windows, or at least tie into it very closely.

> What do you think?
It's Phoronix, so just forget about it. That are nice numbers, but what did he 
compare? Always the same problems with Phoronix, just numbers picked up from 
/dev/random without saying anything real. So unless we get informations on how 
exactly the tests where performed and if the same tests are rerun for kwin 
under correct circumstances (tested with a large set of hardware and not just 
on one system as Phoronix normaly does) we can safely ignore anything coming 
from Phoronix.
Comment 64 Martin Flöser 2010-05-21 18:31:59 UTC
Here a blog post from Compiz dev to the benchmark: http://smspillaz.wordpress.com/2010/05/21/beware-the-benchmarks/
Comment 65 Victor Gavrish 2010-05-21 19:18:37 UTC
@64: That article seems to agree on the conclusion relevant to this bug, though:

"The phoronix benchmarks point out the obvious and you have a choice between horrible rendering glitches or a slight performance hit."

I think this unredirecting fullscreen windows is essentially choosing "horrible rendering glitches" rather than "a slight performance hit".
Comment 66 Martin Flöser 2010-05-21 19:29:23 UTC
> "The phoronix benchmarks point out the obvious and you have a choice
> between horrible rendering glitches or a slight performance hit."
Yes it's the obvious - it's nothing we haven't known for years. In the case of 
KDE default I think we have to stick to the better performance as we have to 
find the best solution for our whole userbase.

The distributions are able to do a different choice better suited for their 
targeted user group. I know of at least Kubuntu disabling unredirect 
fullscreen windows by default and I completely agree with them on the 
decision.

So you see in this small statement I was able to contradict myself by once 
arguing for enabling it and disabling it. It's just impossible to do the 
correct choice. Best would be to just fix the bug (annoys me at work, so it 
might happen that I investigate it)
Comment 67 Alexander 2010-05-29 10:46:20 UTC
I have the same when watching a video in VLC. The screen flickers once, when I start moving mouse to see the floating toolbar. Problem disappears immediately after disabling Kwin compositing.

Arch Linux 2.6.34 (x86-64)
Qt 4.6.2
KDE 4.4.3
Comment 68 Christoph Feck 2010-06-07 23:16:50 UTC
*** Bug 240747 has been marked as a duplicate of this bug. ***
Comment 69 Ivan Lezhnjov Jr. 2010-06-19 10:34:08 UTC
Just to confirm this is still a problem for me. 

KDE 4.4.4, ArchLinux build
qt 4.6.3-1 
using xf86-video-ati 6.12.192-1 and ati-dri 7.7.1-1 (if it matters?)

and it's an on-board ATI Xpress 1250 video chip.

Disabling unredirecting solves the issue.
Comment 70 Alexander 2010-07-14 13:47:18 UTC
The problem is gone when I've installed and enabled kwin beclock effect. Now there is no flicker with fullscreen applications.
Comment 71 Thomas Lübking 2010-07-14 15:46:12 UTC
sounds like a _really_ old version?!
it used to be a fullscreen effect, preventing unredirecting - but that's no more the case. if you want to prevent unredirection, set the relevant config item (see comment #2)

Current versions don't behave like this as it has a bad impact on performance.
Comment 72 Ivo Anjo 2010-07-14 15:57:53 UTC
(In reply to comment #70)
> The problem is gone when I've installed and enabled kwin beclock effect. Now
> there is no flicker with fullscreen applications.

I'm guessing that's because for beclock to work, compositing always has to be on, so it's the same as disabling the Unredirect option.
Comment 73 Alexander 2010-07-14 16:18:59 UTC
Old version of beclock? It's 0.12-1.

Actually, after removing beclock, flickering doesn't returned back. But I am absolutely sure that the "UnredirectFullscreen" option has been false and previously, because I've checked it out before installing beclock.
Comment 74 Thomas Lübking 2010-07-14 16:39:26 UTC
the current version. seems to be a bug (on initial load??)
-> suspending/resuming compositing resolves this.
i'll have a look, but this is not intended...
Comment 75 Alexander 2010-07-15 16:30:19 UTC
UnredirectFullscreen=false cause low performance in 3D games, right? Even mouse cursor moves choppy in nexuiz. So, seems UnredirectFullscreen isn't a solution.
Comment 76 Alexander 2010-07-17 22:19:51 UTC
Nexuiz... even HD video plays with jerks. They are not very noticeable, but they 100% are and they annoy.
Comment 77 Thomas Lübking 2010-07-17 22:39:02 UTC
whatever causes it: NOT unredirecting fullscreen window has bad impact on performance. that is well known and the reason why it's not activated by default - no need to report  that ;-)
Comment 78 Diederik van der Boor 2010-07-29 23:26:42 UTC
Just a suggestion, would it be possible to paint small windows (like tooltips) just on top of the fullscreen window? Like, as it used to be done before compositing was even invented?

I think that would fix the major reason for the flickering the happen: a little tooltip window. Others contenders are context menu's - when browsing with firefox in fullscreen.
Comment 79 Martin Flöser 2010-07-30 06:54:36 UTC
> Just a suggestion, would it be possible to paint
> small windows (like
tooltips) just on top of the fullscreen window?
No, as this would require
more work than finally fixing this bug. It's on my agenda for 4.6 (which
does not mean I will fix it, it's just on the agenda)
Comment 80 cyrus_xiii 2010-08-04 04:27:40 UTC
> even HD video plays with jerks.

I experienced said performance decrease with X11 output (VLC) but not with XVideo. (Just putting this out there for other users, since we may have to make do with the workaround for a little while longer.)
Comment 81 Martin Flöser 2010-08-13 17:39:47 UTC
*** Bug 247656 has been marked as a duplicate of this bug. ***
Comment 82 Martin Flöser 2010-09-17 19:37:29 UTC
SVN commit 1176432 by graesslin:

Adding checkbox for unredirecting fullscreen windows.
FEATURE: 232532
CCBUG: 177495
FIXED-IN: 4.6.0

 M  +4 -0      main.cpp  
 M  +19 -9     main.ui  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1176432
Comment 83 p92 2010-10-21 16:26:17 UTC
in the meantime one can use  ksnapshot  or shutter
Comment 84 Martin Flöser 2010-11-15 18:53:04 UTC
*** Bug 255975 has been marked as a duplicate of this bug. ***
Comment 85 peto.milan 2010-12-02 22:18:07 UTC
(In reply to comment #2)
> If we don't find a solution for it than we should set UnredirectFullscreen to
> false by default. I think the flickering is worse than the problems with videos
> or OpenGL application and for these cases we have the shortcut to suspend
> compositing.
> 
> You can disable unredirecting the following way:
> 1. open ~/.kde/share/config/kwinrc in an editor
> 2. go to section [Compositing]
> 3. Add following line:
> UnredirectFullscreen=false
> 4. Save file and restart kwin (alt+f2 and kwin --replace)

This really helped for my VLC issue on KDE 4.5
Comment 86 peto.milan 2010-12-02 22:23:20 UTC
*** Bug 258611 has been marked as a duplicate of this bug. ***
Comment 87 Ivo Anjo 2010-12-02 22:25:48 UTC
One thing I still don't understand, is that this also happens in intel and AMD systems for which there is DRI2 support.

Shouldn't the usage of DRI2 avoid this problem? This is more of an open question to kwin devs out there.

But yeah, I've got unredirect disabled on all my systems, got too tired of flickering in xbmc/smplayer/...
Comment 88 Martin Flöser 2010-12-02 22:31:38 UTC
> Shouldn't the usage of DRI2 avoid this problem? This is more of an open
> question to kwin devs out there.
Even with DRI2 it's still a valid option to unredirect fullscreen windows. 
There are applications which perform better. So I disable effects at all 
whenever I watch videos for example.

This is one of the problems which I doubt will be fixable before we have 
Wayland.

Btw the Maemo Compositor has that problem, too. And there it is even more 
annoying as it is basicly whenever you switch the running window.
Comment 89 Ivo Anjo 2011-01-14 20:57:01 UTC
(In reply to comment #88)
> Btw the Maemo Compositor has that problem, too. And there it is even more 
> annoying as it is basicly whenever you switch the running window.

Today I was happily using my Maemo device (heh just wanted to brag), and it hit me -- you say that the Maemo compositor does this, and yet I've never noticed any kind of flickering.

If this is the case, wouldn't the same approach taken by Maemo work for kwin? Or do they do embedded-device-custom-X-patches-foo in order to do the same without any kind of visual artifacts?

Ps: Thanks for your feedback so far.
Comment 90 Martin Flöser 2011-01-14 21:27:01 UTC
On Friday 14 January 2011 20:57:08 Ivo Anjo wrote:
> Today I was happily using my Maemo device (heh just wanted to brag), and it
> hit me -- you say that the Maemo compositor does this, and yet I've never
> noticed any kind of flickering.
I noticed it on the first day and the flickering there is pretty bad (long 
delay till the window is visible again). The difference is that they don't 
have windows opening on top of the fullscreen window (e.g. no menus, no 
notifications).
> 
> If this is the case, wouldn't the same approach taken by Maemo work for
> kwin? 
If you can find out what they do differently ;-)
Comment 91 Ivo Anjo 2011-01-14 21:43:47 UTC
(In reply to comment #90)
> On Friday 14 January 2011 20:57:08 Ivo Anjo wrote:
> > Today I was happily using my Maemo device (heh just wanted to brag), and it
> > hit me -- you say that the Maemo compositor does this, and yet I've never
> > noticed any kind of flickering.
> I noticed it on the first day and the flickering there is pretty bad (long 
> delay till the window is visible again). The difference is that they don't 
> have windows opening on top of the fullscreen window (e.g. no menus, no 
> notifications).

They do have notifications (when you get a new e-mail or sms), and pure gtk applications (normally in the extras-devel repository) do have menus. I've only really noticed problems with quake3 and some other very heavy, not really finished ports.

I just remembered: it is noticeable when some games get redirected because their framerate drops (normally to show "low battery" notifications), but I don't remember ever seeing flickering there to transfer between modes.

> > If this is the case, wouldn't the same approach taken by Maemo work for
> > kwin? 
> If you can find out what they do differently ;-)

Heh, I don't really grok opengl at all. Might be a nice opportunity to start :)
Comment 92 Martin Flöser 2011-07-19 16:47:43 UTC
*** Bug 278024 has been marked as a duplicate of this bug. ***
Comment 93 Martin Flöser 2011-08-14 07:34:41 UTC
FYI: in 4.7 we changed the default to no longer use unredirection of fullscreen windows.
Comment 94 Martin Flöser 2012-01-26 16:13:49 UTC
*** Bug 292462 has been marked as a duplicate of this bug. ***
Comment 95 Martin Flöser 2012-09-19 12:07:51 UTC
It no longer flickers thanks to fixes in X as I just learned.
Comment 96 Ivo Anjo 2012-09-19 12:49:20 UTC
(In reply to comment #95)
> It no longer flickers thanks to fixes in X as I just learned.

OH MY GOD. Really? Can you point out any commit/feature/version?
I've been waiting for this for so long!!! I just want to buy someone a beer or an entire keg!