Tearing on secondary monitors even when "Sync To VBlank" is turned on.

Bug #201342 reported by litemotiv on 2008-03-12
This bug affects 10 people
Affects Status Importance Assigned to Milestone
Compiz Linaro Team
compiz (Ubuntu)
Declined for Maverick by Sebastien Bacher

Bug Description

Binary package hint: compiz

When using 2 separate X screens with Vsync on, Compiz should honor each screen's refreshrate independently. Instead it pushes a single refresh, causing tearing on one of the screens when both screens are not in perfect sync.

Ubuntu Hardy
compiz-core 1:0.7.2-0ubuntu1

Dell XPS M1330 laptop (Intel Core2Duo T7500, 2GB ram, Nvidia 8400M GS, internal monitor and external Dell 2405FPW)


Enable "Force full screen redraws (buffer swap) on repaint" in the Workarounds section of CCSM. If you don't have ccsm installed, you can get it by installing package "compizconfig-settings-manager".


1) Use a dual-monitor setup with 2 separate X screens
2) Start Compiz with Vsync enabled
3) Move a window around both screens

You will find that screen 0 shows no sign of tearing, screen 1 will show a single large tearline running down the screen, timed at the clock difference between both screens.

A bit more information taken from a post to Nvidia corp.:

i have a twinview setup with 2 lcd's: nvidia-settings says screen 1 has a 59.99hz refreshrate, screen 2 has 59.95hz.

as a result, with vsync on (without is undoable), one of the screens always has one major tearline running down very slowly. the other one is smooth. depending on which screen i make primary, the other one starts to tear.

so i guess that sort of makes sense, as the screens are slightly out of sync, but isnt there a way to make both screen vsync correctly? i tried running 2 separate x screens but that doesnt seem to be the solution (compiz is still only using 1 global refreshrate).

In TwinView, there's only one video memory surface for the screen, so it's only possible to sync to one or the other. To sync to both at the same time, you'd need to wait for the refreshes to line up again, which happens every 1/(59.99 Hz - 59.95 Hz) = 25 seconds = unacceptable. One thing you could try is to use identical mode timings for both screens, if your display devices can handle it.

With two separate X screens, you can swap each one independently so you should be able to get tear-free swaps on both screens. If Compiz can't do it, that sounds like a bug in Compiz.

-AaronP, Nvidia Corporation.

Related branches

Changed in compiz:
importance: Undecided → Wishlist
milestone: none → later
status: New → Confirmed
PsYcHoK9 (psychok9) wrote :

I've the same bug with nVidia card and Jaunty.
Please fix it soon!

Changed in compiz (Ubuntu):
importance: Wishlist → Low
status: Confirmed → Triaged
summary: - Compiz uses single refreshrate with separate X screens
+ Uses single refreshrate with separate X screens
summary: - Uses single refreshrate with separate X screens
+ Uses single refreshrate for separate X screens

I can confirm this issue on my Dell laptop (D830, Quadro NVS135M GPU with 190.18 binary nvidia drivers). My external CRT operates at 85Hz, while my laptop runs at 60Hz, but Compiz can only use one refresh rate for both screens.

Compiz should be able to set one refresh rate per x screen, instead of one refresh rate for everything (glXSwapBuffers calls are independent for each screen / OpenGL context).

ChrT (klemen-grm) on 2009-11-10
Changed in compiz (Ubuntu):
status: Triaged → Confirmed
Changed in compiz (Ubuntu):
status: Confirmed → Triaged
Adrian Wilkins (adrian-wilkins) wrote :

Noticed this again recently because the "primary" screen appears to have switched between driver versions.

Despite what's said above, on my hardware the driver seems to pick the screen it syncs to and does not respect the "primary" setting for this purpose.

Previously this meant that I had flipped my monitor cables around (and flipped the screen config around in Windows) so that the synced display was my primary display and the tearing was on the secondary. Now the sync has shifted to the other display so I guess I'll be flipping my cables around again.

This is most noticeable when playing video as one does not drag screens around constantly. I have a feeling that in many cases bugs like #151674 are probably also attributable to this fault.

Isn't this down to some awful kludge in X that identifies displays by a concatenation of their resolution and refresh rate - the end result being that you can't have two displays with identical resolutions and refresh rates because that would mean X couldn't tell them apart? It would seem to be worth checking this rumour out but I don't have the time or grok C and X well enough.

summary: - Uses single refreshrate for separate X screens
+ Tearing on secondary monitors even when "Sync To VBlank" is turned on.
Daniel van Vugt (vanvugt) wrote :

This is still an issue in Ubuntu 11.04 and 11.10beta2.

Since I have uploaded fixes to the relevant compiz code recently, I have two suggestions that might fix this for compiz:

1. Switch GLX contexts at the right time. It seems like compiz is still in the context of screen 0 when it's doing the wait for sync on screen N>0. I got this idea from the official docs: http://www.opengl.org/registry/specs/SGI/video_sync.txt

2. Remove the old-fashioned Vsync waiting calls from compiz and use SGI_GLX_swap_control for everything:

I have *partially* implemented #2 in compiz as part of the fix for bug 763005 already. However we won't be able to remove the Vsync waiting logic until/unless the compiz opengl plugin is changed to use glXSwapBuffers for every single frame. Presently compiz only calls glXSwapBuffers occasionally, so SGI_GLX_swap_control can't yet be used for all frames.

Daniel van Vugt (vanvugt) wrote :

Added a workaround in the bug description. I think it's exactly what Aaron P. of Nvidia was talking about...


Enable "Force full screen redraws (buffer swap) on repaint" in the Workarounds section of CCSM. If you don't have ccsm installed, you can get it by installing package "compizconfig-settings-manager".

description: updated
Daniel van Vugt (vanvugt) wrote :

This will be fixed by the fix for bug 901097 in the gles2 branch, which is going to land soon to be released in compiz

Changed in compiz:
status: New → In Progress
assignee: nobody → Compiz Linaro Team (compiz-linaro-team)
importance: Undecided → Low
milestone: none →
Christoph Buchner (bilderbuchi) wrote :

great, thank you! "eliminate all tearing once and for all" sounds too good to be true! :-)

Daniel van Vugt (vanvugt) wrote :

Fix committed into lp:compiz at revision 3320

Changed in compiz:
status: In Progress → Fix Committed
Changed in ubutter:
status: New → Fix Committed
importance: Undecided → Low
Changed in compiz:
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package compiz - 1:

compiz (1: quantal-proposed; urgency=low

  * debian/control, debian/rules:
    - enable gles on armel and armhf
    - use dh-translations rather than custom code

  [ Sam Spilsbury ]
  * Enable OpenGL ES building
    - Refresh debian/patches/workaround_broken_drivers.patch
    - Remove non-ported plugins from compiz-plugins
    - Add FindOpenGLES2.cmake to compiz-dev

  [ Timo Jyrinki ]
  * New upstream release.
    - Code to make compiz work on GLES. This includes several changes
      to the compiz API. (LP: #201342) (LP: #901097) (LP: #1004251)
      (LP: #1037710)
    - Draft first NEWS and bump VERSION
  * debian/patches/compiz-package-gles2.patch:
    - Remove, obsoleted by the upstream GLES work
  * Disable plugins that don't work on pure GLES on armhf/armel:
    - bench, firepaint, mblur, showmouse, splash, showrepaint, td, widget
 -- Sebastien Bacher <email address hidden> Fri, 31 Aug 2012 22:59:50 +0200

Changed in compiz (Ubuntu):
status: Triaged → Fix Released
Changed in ubutter:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers