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.
I don't think it is related to drivers as I am experiencing the same behaviour with nVidia.
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)
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 =)
*** Bug 179859 has been marked as a duplicate of this bug. ***
*** Bug 184020 has been marked as a duplicate of this bug. ***
*** Bug 185067 has been marked as a duplicate of this bug. ***
Created attachment 31744 [details] Package manager's log file before the flickering started
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.
Hm, could also be related to this bug: https://bugs.kde.org/show_bug.cgi?id=184002
*** Bug 184002 has been marked as a duplicate of this bug. ***
Happens here, too, with x11-drivers/nvidia-drivers-180.22 on Gentoo.
*** Bug 191082 has been marked as a duplicate of this bug. ***
*** Bug 194872 has been marked as a duplicate of this bug. ***
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
Same problem here. Debian SID KDE 4.2.4 nVidia drivers: I tried 180.60 and 185.18.14
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.
it's not like "~/.kde4/..." for you, is it?
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.
(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).
(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/ :|
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?
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.
*** Bug 201148 has been marked as a duplicate of this bug. ***
*** Bug 201777 has been marked as a duplicate of this bug. ***
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?
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? ;-)
(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".
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.
*** Bug 206360 has been marked as a duplicate of this bug. ***
*** Bug 208948 has been marked as a duplicate of this bug. ***
*** Bug 209096 has been marked as a duplicate of this bug. ***
*** Bug 209868 has been marked as a duplicate of this bug. ***
Does this bug include instances where the entire screen flickers off and may cause the monitor/card to turn off?
(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?
Bug 180767 looks like another duplicate of this one.
*** Bug 180767 has been marked as a duplicate of this bug. ***
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?
*** Bug 217750 has been marked as a duplicate of this bug. ***
*** Bug 220210 has been marked as a duplicate of this bug. ***
happen to mee to. opensuse 11.2, kde 4.3 intel 965. when hover down on fullscreen, screen flicker instead of showing seek bar.
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.
*** Bug 224939 has been marked as a duplicate of this bug. ***
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.
*** Bug 225231 has been marked as a duplicate of this bug. ***
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 ;)
(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.
I noticed the problem also existis with XRender backend, so it is not OpenGL specific.
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.
(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.
@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 :(
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
performance, just read this thread (maybe try comment #18 first ;-)
#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.
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.
are there any benchmarks which show, how much performance is lost when using UnredirectFullscreen=false?
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.
@#56: What video driver are you using?
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.
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...
@57: I am using the binary Nvidia driver, version 185.18.36
rm my cc..way too high traffic for me.
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 #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.
Here a blog post from Compiz dev to the benchmark: http://smspillaz.wordpress.com/2010/05/21/beware-the-benchmarks/
@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".
> "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)
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
*** Bug 240747 has been marked as a duplicate of this bug. ***
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.
The problem is gone when I've installed and enabled kwin beclock effect. Now there is no flicker with fullscreen applications.
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.
(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.
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.
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...
UnredirectFullscreen=false cause low performance in 3D games, right? Even mouse cursor moves choppy in nexuiz. So, seems UnredirectFullscreen isn't a solution.
Nexuiz... even HD video plays with jerks. They are not very noticeable, but they 100% are and they annoy.
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 ;-)
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.
> 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)
> 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.)
*** Bug 247656 has been marked as a duplicate of this bug. ***
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
in the meantime one can use ksnapshot or shutter
*** Bug 255975 has been marked as a duplicate of this bug. ***
(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
*** Bug 258611 has been marked as a duplicate of this bug. ***
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/...
> 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.
(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.
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 ;-)
(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 :)
*** Bug 278024 has been marked as a duplicate of this bug. ***
FYI: in 4.7 we changed the default to no longer use unredirection of fullscreen windows.
*** Bug 292462 has been marked as a duplicate of this bug. ***
It no longer flickers thanks to fixes in X as I just learned.
(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!