Compiz

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	Fix Released	Low	Compiz Linaro Team	Compiz 0.9.8.0
	Ubutter	Fix Released	Low	Unassigned
	compiz (Ubuntu)	Fix Released	Low	Unassigned	Ubuntu later
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)

WORKAROUND:

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".

TEST CASE:

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.:

[question]
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).

[answer]
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.

See original description

Related branches

lp://staging/~compiz-linaro-team/compiz/gles2

Merged into lp://staging/compiz/0.9.8 at revision 3320

Daniel van Vugt: Approve on 2012-08-22

Sam Spilsbury: Approve on 2012-08-21

Tim Penhey: Pending requested 2012-08-20

Alan Griffiths: Pending requested 2012-08-20

jenkins: Pending (continuous-integration) requested 2012-08-20

Diff: 16838 lines (+7498/-4718)

104 files modified

cmake/CMakeLists.txt (+2/-0)
cmake/CompizCommon.cmake (+12/-0)
cmake/CompizPlugin.cmake (+14/-10)
cmake/FindCompiz.cmake (+1/-1)
cmake/FindOpenGLES2.cmake (+51/-0)
cmake/base.cmake (+3/-0)
cmake/plugin_extensions/CompizOpenGLFixups.cmake (+22/-0)
include/core/wrapsystem.h (+8/-0)
plugins/CMakeLists.txt (+30/-0)
plugins/animation/CMakeLists.txt (+3/-5)
plugins/animation/include/animation/animation.h (+1/-1)
plugins/animation/include/animation/animeffect.h (+3/-3)
plugins/animation/include/animation/grid.h (+0/-2)
plugins/animation/src/animation.cpp (+85/-27)
plugins/animation/src/grid.cpp (+25/-258)
plugins/animation/src/private.h (+3/-3)
plugins/annotate/src/annotate.cpp (+149/-71)
plugins/blur/CMakeLists.txt (+12/-12)
plugins/clone/src/clone.cpp (+0/-5)
plugins/compiztoolbox/src/compiztoolbox.cpp (+5/-18)
plugins/copytex/src/copytex.cpp (+9/-0)
plugins/cube/include/cube/cube.h (+9/-6)
plugins/cube/src/cube.cpp (+85/-80)
plugins/decor/src/decor.cpp (+29/-27)
plugins/decor/src/decor.h (+2/-2)
plugins/expo/CMakeLists.txt (+4/-8)
plugins/expo/src/expo.cpp (+256/-111)
plugins/expo/src/expo.h (+3/-4)
plugins/ezoom/src/ezoom.cpp (+118/-52)
plugins/grid/src/grid.cpp (+108/-53)
plugins/imgsvg/src/imgsvg.cpp (+9/-6)
plugins/imgsvg/src/imgsvg.h (+2/-1)
plugins/kdecompat/src/kdecompat.cpp (+7/-22)
plugins/mag/src/mag.cpp (+102/-73)
plugins/mag/src/mag.h (+2/-0)
plugins/neg/src/neg.cpp (+33/-106)
plugins/neg/src/neg.h (+3/-6)
plugins/obs/src/obs.cpp (+8/-7)
plugins/obs/src/obs.h (+1/-1)
plugins/opengl/CMakeLists.txt (+14/-4)
plugins/opengl/compiz-opengl.pc.in (+1/-1)
plugins/opengl/include/opengl/doublebuffer.h (+39/-0)
plugins/opengl/include/opengl/fragment.h (+0/-125)
plugins/opengl/include/opengl/framebufferobject.h (+104/-0)
plugins/opengl/include/opengl/matrix.h (+2/-0)
plugins/opengl/include/opengl/opengl.h (+441/-73)
plugins/opengl/include/opengl/program.h (+75/-0)
plugins/opengl/include/opengl/programcache.h (+51/-0)
plugins/opengl/include/opengl/shadercache.h (+100/-0)
plugins/opengl/include/opengl/texture.h (+5/-0)
plugins/opengl/include/opengl/vector.h (+3/-3)
plugins/opengl/include/opengl/vertexbuffer.h (+130/-0)
plugins/opengl/opengl.xml.in (+15/-0)
plugins/opengl/src/doublebuffer/CMakeLists.txt (+31/-0)
plugins/opengl/src/doublebuffer/src/double-buffer.cpp (+76/-0)
plugins/opengl/src/doublebuffer/tests/CMakeLists.txt (+24/-0)
plugins/opengl/src/doublebuffer/tests/test-opengl-double-buffer.cpp (+98/-0)
plugins/opengl/src/fragment.cpp (+0/-1146)
plugins/opengl/src/framebufferobject.cpp (+221/-0)
plugins/opengl/src/matrix.cpp (+54/-0)
plugins/opengl/src/paint.cpp (+472/-443)
plugins/opengl/src/privatefragment.h (+0/-54)
plugins/opengl/src/privates.h (+101/-13)
plugins/opengl/src/privatetexture.h (+32/-0)
plugins/opengl/src/privatevertexbuffer.h (+149/-0)
plugins/opengl/src/program.cpp (+262/-0)
plugins/opengl/src/programcache.cpp (+175/-0)
plugins/opengl/src/screen.cpp (+938/-154)
plugins/opengl/src/shadercache.cpp (+246/-0)
plugins/opengl/src/texture.cpp (+152/-22)
plugins/opengl/src/vector.cpp (+2/-2)
plugins/opengl/src/vertexbuffer.cpp (+634/-0)
plugins/opengl/src/window.cpp (+65/-83)
plugins/resize/src/resize.cpp (+84/-31)
plugins/resizeinfo/src/resizeinfo.cpp (+45/-27)
plugins/resizeinfo/src/resizeinfo.h (+2/-1)
plugins/ring/src/ring.cpp (+19/-37)
plugins/ring/src/ring.h (+1/-1)
plugins/scale/src/scale.cpp (+10/-17)
plugins/scaleaddon/src/scaleaddon.cpp (+51/-21)
plugins/scaleaddon/src/scaleaddon.h (+2/-2)
plugins/scalefilter/src/scalefilter.cpp (+1/-6)
plugins/screenshot/src/screenshot.cpp (+47/-20)
plugins/shift/src/shift.cpp (+95/-98)
plugins/shift/src/shift.h (+1/-1)
plugins/staticswitcher/src/staticswitcher.cpp (+156/-64)
plugins/staticswitcher/src/staticswitcher.h (+5/-3)
plugins/switcher/src/switcher.cpp (+45/-42)
plugins/text/include/text/text.h (+2/-1)
plugins/text/src/text.cpp (+53/-24)
plugins/thumbnail/src/thumbnail.cpp (+301/-118)
plugins/thumbnail/src/thumbnail.h (+3/-1)
plugins/wall/src/wall.cpp (+60/-46)
plugins/wall/src/wall.h (+1/-1)
plugins/water/src/shaders.h (+200/-0)
plugins/water/src/water.cpp (+281/-801)
plugins/water/src/water.h (+33/-63)
plugins/water/water.xml.in (+26/-2)
plugins/wobbly/src/wobbly.cpp (+20/-176)
plugins/wobbly/src/wobbly.h (+0/-1)
plugins/workarounds/src/workarounds.cpp (+14/-0)
plugins/workarounds/src/workarounds.h (+4/-0)
plugins/workspacenames/src/workspacenames.cpp (+4/-8)
plugins/workspacenames/src/workspacenames.h (+1/-1)

Travis Watkins (amaranth) on 2008-03-12

Changed in compiz:
importance:	Undecided → Wishlist
milestone:	none → later
status:	New → Confirmed

Revision history for this message

PsYcHoK9 (psychok9) wrote on 2009-05-27:

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

Robert Ancell (robert-ancell) on 2009-06-15

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

Revision history for this message

The Fiddler (stapostol) wrote on 2009-09-07: Re: 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

Travis Watkins (amaranth) on 2009-11-11

Changed in compiz (Ubuntu):
status:	Confirmed → Triaged

Revision history for this message

Adrian Wilkins (adrian-wilkins) wrote on 2010-04-13:

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.

Daniel van Vugt (vanvugt) on 2011-10-03

summary:

- Uses single refreshrate for separate X screens
+ Tearing on secondary monitors even when "Sync To VBlank" is turned on.

Revision history for this message

Daniel van Vugt (vanvugt) wrote on 2011-10-03:

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:
http://www.opengl.org/wiki/Swap_Interval
http://www.opengl.org/registry/specs/SGI/swap_control.txt

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.

Revision history for this message

Daniel van Vugt (vanvugt) wrote on 2011-10-31:

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

WORKAROUND:

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

Revision history for this message

Daniel van Vugt (vanvugt) wrote on 2012-08-21:

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 0.9.8.0.

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

Revision history for this message

Christoph Buchner (bilderbuchi) wrote on 2012-08-21:

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

Revision history for this message

Daniel van Vugt (vanvugt) wrote on 2012-08-23:

Fix committed into lp:compiz at revision 3320

Changed in compiz:
status:	In Progress → Fix Committed

Daniel van Vugt (vanvugt) on 2012-08-23

Changed in ubutter:
status:	New → Fix Committed
importance:	Undecided → Low

Daniel van Vugt (vanvugt) on 2012-08-27

Changed in compiz:
status:	Fix Committed → Fix Released

Revision history for this message

Launchpad Janitor (janitor) wrote on 2012-09-01:

This bug was fixed in the package compiz - 1:0.9.8.0-0ubuntu1

---------------
compiz (1:0.9.8.0-0ubuntu1) 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 0.9.8.0 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

Daniel van Vugt (vanvugt) on 2012-09-20

Changed in ubutter:
status:	Fix Committed → Fix Released

Report a bug

This report contains Public information

Everyone can see this information.

You are

Subscribing...

Edit bug mail

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.