Comment 92 for bug 755841

(In reply to comment #55)
> With compositing enabled, I guess there is not much to do - the problem happens
> due to the nature of compositing itself. When it is used, the windows do not
> render directly to screen, but to an off-screen area. So the vsync is not
> helpful in any case - the off-screen does not synchronizes itself with it. Such
> tearing is not Intel-specific, it also happens on nvidia
> (http://www.nvnews.net/vbulletin/showthread.php?t=149276,
> http://nvnews.net/vbulletin/showthread.php?t=149776), and there is a nice
> description at https://bugzilla.gnome.org/show_bug.cgi?id=562669 as well.

In such cirumstances,the compositor uses CopySubBuffer which is meant to be vsync'ed.The caveat is that it is implemented inside an Xserver using a function that is not specified to be either synchronous or asynchronous (DRI2CopyRegion), and that same function is also used in a performance sensitive path (vblank_mode=0!). For UXA, we actually do enable vsync so that the compositor does not tear. I proposed http://cgit.freedesktop.org/~ickle/xserver/commit/?id=9e92c256853fa29bddd27e41fdd24e0b140e7fd4 to disambiguate that case and to permit even faster vblank_mode=0 swapping.