(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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/755841 Title: [sandybridge] video tearing To manage notifications about this bug go to: https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/755841/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
