I'm on the latest xfwm4 on gentoo and the window decorations will sometimes blink randomly. It must be related to the new vsync stuff. It happens a lot but I not completely reliably so I cant give very reliable steps to repro :(. It happens less on maximized things, and much more when the windows are unmaximized. Compositor off and Xpresent are fine: $ xfwm4 --replace --compositor=off & $ XFWM4_USE_PRESENT=1 xfwm4 --replace & If i switch back to epoxy then i get blinks randomly: $ xfwm4 --replace & Some things that trigger it (unreliably): - switching through workspaces really quickly with the scroll wheel - open https://git.xfce.org/ in chrome and have a terminal or other window on top then move the cursor over the text for a while and the decorations disappear then very quickly reappear. Sometimes if i move the mouse slower it takes longer to reappear? I have these versions installed: media-libs/libepoxy-1.4.1 media-libs/mesa-13.0.5 $ xfwm4 -V This is xfwm4 version 4.13.0 (revision a46bb00) for Xfce 4.12 Released under the terms of the GNU General Public License. Compiled against GTK+-2.24.31, using GTK+-2.24.31. Build configuration and supported features: - Startup notification support: Yes - XSync support: Yes - Render support: Yes - Xrandr support: Yes - Xpresent support: Yes - Embedded compositor: Yes - Epoxy support: Yes - KDE systray proxy (deprecated): No I'm using the modesetting driver and have an intel integrated gfx chip. Let me know how I can help debug further :)
I just tried glxgears and a movie in mpv using the opengl-hq rendering and those dont appear to blink when the window decorations do so less likely that its opengl is completely broken. if I untick sync_to_vblank in settings editor->xfwm4 then whole windows blink instead of just the window decorations and i see the window behind for a split second.
Yes, I saw that as well, I think this is a GL issue with some HW, I suspect we should default to Xpresent (btw, the "vsync" option should be removed)
I am also getting frequent flickering on 4.13 when the compositor is enabled. This happens most often with panel plugins and partially transparent windows. During flickers, the section of the screen seems to disappear, or blank with a solid color, or a part of the underlying window becomes visible. Compiling in xpresent or not does not seem to make a difference. Disabling vsync makes the flickering *much* worse, occuring almost every time on damaged screen elements, whereas it's only seen every few seconds with vsync enabled. This is using Intel drivers on Ivy Bridge hardware. Xfwm4-4.12 is unaffected.
I just noticed that the Xpresent extension needs to be enabled via env var. Doing so solves flickering! However it causes a hardware-accelerated Firefox to enter idiot mode (no or very delayed screen updates). This is a Firefox bug tho.
(In reply to haarp from comment #3) > I am also getting frequent flickering on 4.13 when the compositor is > enabled. This happens most often with panel plugins and partially > transparent windows. During flickers, the section of the screen seems to > disappear, or blank with a solid color, or a part of the underlying window > becomes visible. What you describe here is exactly the situation that I found myself in today and I don't really know what exactly causes this. I've been using Xfwm 4.13.x for quite a while now and never had any issue with flickering or moving windows that for a moment have artifacts inside... until... until I tried Xfwm 4.13.x latest Git, where the vblank code got removed. With composite turned on (and some heavy disk ativiity like rsyncing) I can't even scroll with the cursor in a terminal anymore. Everyhing goes on sluggish, characters seem to be hanging (or eaten) for a moment or scrolling down within "midnight commander" simply hangs or places the cursor elsewhere (because of continued moving but hanging because of no refreshing the display). Same applies with stuttering playback of movies etc. Dunno how to describe this exactly. Turning off compositor makes everything goes on normally. What I also noticed (and this starting with Xfwm 4.13.x (4.12.x is not affected), that after logging in from lightdm into the Xfce4 session, that for a few seconds (2-3 seconds) I get a corrupt background (the wallpaper is being totally corrupted) and then when xfdesktop loads up, it fixes the corruption again. Haven't tested this with disabled compositor. > Compiling in xpresent or not does not seem to make a difference. Disabling > vsync makes the flickering *much* worse, occuring almost every time on > damaged screen elements, whereas it's only seen every few seconds with vsync > enabled. xpresent.... hmmmm.... I think I need to give it a shot.
(In reply to Jason Zaman from comment #0) > I'm using the modesetting driver and have an intel integrated gfx chip. I think I wasnt actually using modesetting. I had both drivers installed then and turns out it was using the intel driver anyway. Now ive completely purged the intel driver and only have modesetting installed and i dont get the flickering anymore. The intel driver is dead anyway and everyone has already or should switch to modesetting so this bug probably isnt a huge deal.
Olivier Fourdan referenced this bugreport in commit d6e7fbc4aa17018dd30a7bac1867947d948c9f57 compositor: Use a fence to sync X and GL https://git.xfce.org/xfce/xfwm4/commit?id=d6e7fbc4aa17018dd30a7bac1867947d948c9f57
also faced with flickering on i915, the solution was to switch to modesetting. there is no flickering on the i915 since the last update to xfwm4 to 4.13.1.
d6e7fbc4a makes the problem significantly worse for me.
(In reply to Alistair Buxton from comment #9) > d6e7fbc4a makes the problem significantly worse for me. Which hardware/driver is that?
Nvidia. After d6e7fbc4 entire windows blink through other windows. Transparent windows seem particularly affected, and it happens constantly.
Right, unfortunately, I don't have the hardware, nor the driver (and neither the inclination actually) to work on the NVidia closed source driver so it would be great if you could investigate further... Basically, the blinking is due to a lack of synchronization between X and GL, the X pixmap is updated while GL is copying the data, thus causing the "old" content to be copied. To avoid that, commit d6e7fbc4 adds a fence, so it should help (it does at least for the intel and modesettings drivers, I avoids blinking completely here), but if that doesn't in your case then either the fence does not work or the it fences at the wrong time... Could it be some settings in the NVidia driver maybe?
Reverting d6e7fbc4 fixes all the flickering for me.
But reverting is not a fix.
I don't really understand how this fence is supposed to work. I understand how the old code works: first wait for pending X11 calls to finish with glXWaitX, upload the texture, then wait for GL to finish with glXWaitGL. The new code waits for the fence, uploads the texture, then doesn't wait for GL to finish. I don't understand how that can be equivalent?
Also I found this patch that somebody made in Fedora: https://src.fedoraproject.org/fork/churchyard/rpms/xfwm4/c/4516620b39f57d7532e542b06a4eee5e1c8fe60c It looks like they added a fence and removed the glXWaitX call but left in the glXWaitGL call. That would make sense to me, but maybe I just don't understand it - and I don't know how to view that patch in context anyway.
I just tried putting back only the glXWaitGL() call and this fixes all the flickering.
Nice, please attach git patch and I'll push it.
I am not convinced that is the correct fix though. The way it currently works is that X triggers the fence and then waits on it. So when that fires you know the X operations finished, equivalent to glXWaitX(). But it seems like the point of fences is to synchronize X and GL threads running inside the GPU. So X should trigger the fence and GL should wait for it (glWaitSync) and then the reverse should happen after GL is finished with the buffer. There's some discussion of it here: https://devtalk.nvidia.com/default/topic/1043819/linux/compositor-sync-fences-and-redraw-lag-problems/ Including why it's more of a problem on nvidia.
Well, if that fixes the issue for NVidia without regressing for other Open Source drivers, let's land it even if it's not optimal. You can improve it later if you will, only thing is, I would prefer to avoid any hardware/driver specific hacks in the code.
Created attachment 8168 add back glXWaitGL
As far as I can see this patch causes no regression wrt blinking with intel/nvidia so the last part of the commit message is not necessarily accurate.
(In reply to Olivier Fourdan from comment #22) > [...] intel/nvidia so the last part of the commit message is I meant ^^^ "intel/modesettings" here
Perhaps this mesa bug is related: https://bugs.freedesktop.org/show_bug.cgi?id=52930
a bug from 2012...
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfwm4/-/issues/259. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev