I observe video tearing when playing full screen (and not full screen too) videos with mplayer2/mpv and vo=xv:adaptor=0 (XVideo output, adaptor 0 "Intel(R) Textured Video") on Intel GMA X3100 (965GM). Tearing doesn't occur if compositing is turned off. I use the current Xfwm4 git version (4.11.0), and have enabled the sync_to_vblank configuration option. Previously I observed the same tearing with 4.10.1, too. My X.org version is 1.14.3 and the xf86-video-intel driver version is 2.21.15. Steps to reproduce: 1) Enable compositing 2) Use an Intel graphics card (perhaps this happens on others, too) 3) Play a video, specifying the XVideo adaptor #0 output Perhaps this is similar to bug #9314 in case of full screen playback, however, there is no SDL here. If I use adaptor #1 "Intel(R) Video Overlay", then no tearing occurs, though this doesn't work well with compositing, as described in "man intel" (visual artifacts).
I asked on #intel-gfx at FreeNode and received a reply that with the X Render extension (as opposed to OpenGL) tearing is to be expected. Thus this leaves the problem with fullscreen playback. About tearing in fullscreen mode they replied that the WM might not be unredirecting the media player window. How can I check this for xfwm4?
This is fundamentally a dupe of #6371. The problem is a lack of a page-flipping opengl compositor in XFCE. The Intel-specific problem is that modern Intel hardware only supports tear-free rendering when using a page-flipping compositor: "on modern intel hardware it is not possible at all to get tear-free compositing with xrender, because any intel hardware sandybridge or newer requires a page-flipping opengl compositor to get any kind of tear-free output. Unless XFCE ports XFWM to use opengl there isn't really anything they can do about tearing on intel hardware." https://lists.ubuntu.com/archives/xubuntu-devel/2013-August/009223.html "First note that all Intel hardware up to SandyBridge has functional vsync support with no greater cost than stalling the GPU until the blit can proceed. The problem is that with the agressive powersaving of SandyBridge and the greater decoupling between the display engine and the GPU, the ability to delay rendering until a particular scanline had passed was assumed to be a legacy feature and the GPU commands to do so were removed. By presuming that all updates would then be through a compositor using pageflipping (i.e. their primary target, Windows Vista/7/8), they were then able to make further power savings. If you use an OpenGL (really DRI2) compositor that only pageflips (i.e. doesn't try to take "advantage" of MESA_copy_sub_buffer), you will not see any tearing, suffer very little jitter, and maximise the power savings of the GPU. The TearFree option (still in its infancy, and really only a proof-of-principle at this stage) is to make sure that even a bare X only ever pageflips. This is primarily because future hardware will have even more widespread aggressive power savings that assume a compositor, and worst case scenario, the display engine will only be functional with a pageflipping compositor." http://www.phoronix.com/forums/showthread.php?74598-Intel-Linux-Driver-Still-Working-To-Address-Tearing&p=292645#post292645
Also see upstream bug https://bugs.freedesktop.org/show_bug.cgi?id=37686 for more comments about the need for a proper opengl compositor on recent Intel hardware. And bug #10439 "Use GLX for compositing instead of Xrender"
I cannot reproduce this on Intel HD Graphics 5500 with X.org 1.19.3, recent xf86-video-intel master and Xfwm4 master. Xfwm4 now uses OpenGL or X Present compositing.
You're right, closing.