Created attachment 4423
The attached patch adds vsync support to the xfwm compositor, it does this by first syncing all rendering commands to the X server using XSync(), then wait for the vertical blank using dri, and finally render the root buffer onto the root window.
Tearing still happens about 10 pixels below the top of the display, but since this space is usually only occupied by the title bar, it's only visible when dragging a window across the drop of the screen.
- No tearing when dragging windows.
- No tearing when resizing windows.
- No tearing when using the flash plugin in firefox.
- No tearing in windowed OpenGL applications.
- Uses less resources since the fps is limited to the display refreshrate.
- Only works on videodrivers that use DRI, I've only tested it on the Intel HD 3000, but it should also work on AMD gpus, support for Nvidia could be done using OpenGL, but this is a lot of work.
- Blocks xfwm's main loop while waiting on the vertical blank, could possibly be fixed by using multiple root buffers and a separate thread to render a root buffer onto the root window.
- The setting in the window manager tweaks gui doesn't work, I don't know why. For now the sync to vblank setting can be enabled with:
xfconf-query -c xfwm4 -p "/general/sync_to_vblank" -s true
And then restart xfwm.
I forgot to add, in case of a multi monitor setup, vsync will only work on a single monitor.
The XSync might need to be changed to XFlush for better performance.
Created attachment 4433
Version 2 of the vsync patch
Added some improvements:
- Use XFlush() instead of XSync() to increase performance.
- Schedule the next render to be 10 ms after the last vertical blank instead of 10 ms after the first event, but schedule it at least 1 ms in the future, this reduces latency.
I'd appreciate if you can adjust this patch for xfwm4-4.10 (at the moment can't be applied cleanly).
I can't see where I could vote for this patch, but all I can say it's really great improvement to xfwm!
I've attached the adjusted patch for xfwm 4.10, but without gui changes (it doesn't work anyway ;-)). So far everything works as expected, thanks bob!
Created attachment 4460
vsync patch for xfwm 4.10
Created attachment 4465
Version 3, updated to xfwm 4.10
- Updated to xfwm 4.10.
- Fixed log spam when the screen goes into standby, this could prevent the harddrive from spinning down.
- Added refreshrate detection from RandR, calculate the optimal render time using the time from the last vblank and the refreshrate.
I have tested the v3 patch for 4.10 and it really does work, although, as stated, the top ~10 pixels don't quite line up with any moving window. Is there a technical reason for this artifact?
PS: thanks, bob!
Yeah, it's software vsync, so you get the vblank signal in software, and then you tell xorg to render the pixmap on the root window, there's a little bit of delay in this, so there's tearing at the top of the screen.
The only way to fix this is to use something that has hardware vsync, like opengl, but writing that is a pretty major task.
(In reply to comment #12)
> Yeah, it's software vsync, so you get the vblank signal in software, and
> then you tell xorg to render the pixmap on the root window, there's a little
> bit of delay in this, so there's tearing at the top of the screen.
> The only way to fix this is to use something that has hardware vsync, like
> opengl, but writing that is a pretty major task.
A big thank you for the patch, it looks interesting. Couple of comments though:
- Can you avoid diff'ing xfwm4-tweaks-dialog_ui.h, it's a generated file and pollutes the patch
- Can you add a check in autoconf for existence/availability drm/drm.h and #ifdef/#endif the code that depends on it? WOuld be a shame to break on non-linux platforms
Yet I wonder why un-redirecting fullscreen windows is not sufficient... At least with a fullscreen override redirect window.
Un-redirecting fullscreen windows is of course a useful feature, but it's unrelated, this patch adds vsync to the compositor itself, it's to prevent tearing when dragging/resizing windows, windowed media players, flash applications etc.
Created attachment 4784
Patch taking review into account
Here is a patch fixing what you required Olivier.
I decided to keep the option even when not building with libdrm and just to hide the checkbox in that case. That way there is no need to generate a different glade / defaults file.
I have no idea on what is the minimal required version of libdrm, how could I check that? Debian testing has 2.4.33 here and it compiles fine.
By the way, this also fixes the non-working settings dialog. The glade widget name used in the C files was not the one set in the glade file.
Thanks for your work.
One thing I wonder is, are you linking to libdrm now? Because that's not necessary, all that's needed is the drm.h headerfile.
Created attachment 4786
New patch not linking to libdrm
Ok, now patch should not link against libdrm if I got things right.
Is it normal people can choose to enable vsync in a settings dialog? Feels a bit too advanced, can't we 'detect' if this should be enabled?
One reason would be if you have a dual monitor setup, and one monitor is a tv connected via HDMI with the refreshrate set at 24 hertz, if the rendering is synchronized to the tv you'll only get 24 fps on the other monitor as well.
I'm quite noob on patching, could you please forward me some explanation about how to apply this patch?
Best Regards and Thanks for it
If you're on debian or ubuntu, make sure you have xfwm 4.10 installed, make a test directory, cd into it, check out the source using "apt-get source xfwm4", cd into the xfwm4-4.10.0 directory, apply the patch with "patch -p0 < foo.diff" where foo.diff is the downloaded file, cd into the parent directory, build with "dpkg-buildpackage -z --auto-commit", then install the generated .deb files with "sudo dpkg -i *.deb".
Or maybe follow this guide instead: http://www.webupd8.org/2012/10/xfce-sync-to-vblank-support-for-xfwm.html
Apparently someone already supplied a patched build.
Thanks for the answer.
I'm running Xubuntu 13.04 version and the webupd8 team just patched for Xubuntu 12.04/10
I've understood, but I don't know how to download the patch. When I click over attachment 4786 or [details] it redirects me to a page with codes which first few lines are not commented and they not looks like code (like email heads)
I understood that this is the patch, however I don't know what to select from the beginning to the end (actually I don't know where I should start select neither ending the selection) then paste to a .diff file
(In reply to comment #22)
> If you're on debian or ubuntu, make sure you have xfwm 4.10 installed, make
> a test directory, cd into it, check out the source using "apt-get source
> xfwm4", cd into the xfwm4-4.10.0 directory, apply the patch with "patch -p0
> < foo.diff" where foo.diff is the downloaded file, cd into the parent
> directory, build with "dpkg-buildpackage -z --auto-commit", then install the
> generated .deb files with "sudo dpkg -i *.deb".
Sorry for bothering you Bob,
I think I applied the patch, but I don't know if it was successfully applied. I've created a pasteBin with all procedure to you confirm if I patched it correctly.
1 - I had to enter every file to patch (is this correct?)
2 - file configure.ac.in wasn't found, but configure.ac was (I used this last one, correct?)
3 - Hunk ignored in almost every files
4 - every file patching output had this: "can't find file to patch at input line XX", then : "Perhaps you used the wrong -p or --strip option?"
5 - Some Hunks failed patching file settings-dialogs/xfwm4-tweaks-dialog.glade
6 - Seems that only header src/settings.h was successfully patched without any strange output
So, what are your opinions on this?
I'm really a noob about patching. Really sorry, I want to understand this but I don't know nothing about it at this moment(and I'll be glad if you recommend me some useful link information about it).
Thanks & Regards,
Hello and thanks for this patch.
I'm currently using the older v3 (#4465) patch that links to libdrm and it works good with it.
But the current one doesn't apply to configure.ac.in, because it doesn't exists and it doesn't apply a few bits to xfwm4-tweaks-dialog.glade.
I now pointed the patch to configure.ac, ran autoconf in the src directory and changed the missing bits in xfwm4-tweaks-dialog.glade myself.
./configure detects libdrm and it builds fine but vsync doesn't work and there are no options in the tweaks dialog.
Here are the bits that mention libdrm:
checking for libdrm >= 2.4... 2.4.44
checking LIBDRM_CFLAGS... -I/usr/include/libdrm
checking LIBDRM_LIBS... -ldrm
/general/sync_to_vblank is set to true.
I suspect that something went amiss in the libdrm detection code but am no coder myself so that's just a guess.
Currently i am running xfwm4 4.10.1 (v3 patch) and ati-dri-git 56524 on a HD5850 with arch linux.
@Niccola i used patch -p1 < "the.patch" in the same directory as configure.ac
Thanks for reading.
Pushed patch to master with some minor code cleanups. Have fun testing.
Thank you, it works now.
(In reply to comment #27)
> Pushed patch to master with some minor code cleanups. Have fun testing.
Sorry, but I don't understand... What you mean? I don't see any new patch here... How to apply the patch regarding what you said?
I mean, what's the "master" and how to apply it on my system?
Sorry but I'm a real noob on this... and as a developer, I really would like to understand (could you please forward me some lectures?)
Many Thanks, btw
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen live from http://volichat.com/adult-chat-rooms
> *** Bug 260998 has been marked as a duplicate of this bug. ***
There is no bug 260998. Comment 30 seems to be bugzilla spam.
Hi, i hope i 'm in the right place..
I have xfce 4.12 through debian stretch. I can see the vsync setting and i can confirm it is enabled. My laptop has an Intel GMA4500MHD and opengl is running. Some info:
direct rendering: Yes
glx vendor string: SGI
glx version string: 1.4
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset
OpenGL version string: 2.1 Mesa 10.6.3
tearing when dragging windows.
tearing when resizing windows.
tearing when using the flash plugin in firefox.
tearing in windowed OpenGL applications
tearing when watching video (vlc, mplayer, popcorntime)
I am not an advanced user so tell me what kind of information you need in order to test this further.
Vsync support in 4.12 on completely broken, there is no way it can work.
You need got version with either opengl or present support to get a complete tear free compositor.