search

chjj / compton

A compositor for X11.
Other
2.25k stars 501 forks source link

VSync #7

Open ghost opened 12 years ago

ghost commented 12 years ago

Is it possible to implement vsync into compton? I like this compositor very much, but tearing is annoying some time.

chjj commented 12 years ago

I don't think there is any xrender function to explicitly get or wait for the vblank interval. It doesn't have any vsync support. I know the XFCE guys had a problem with this for their compositor. I also think compiz (GL) had a hard time maintaining a vsync feature because it would conflict with video drivers that were also trying to sync to the vblank rate. So even if I could, I would be hesitant about adding this.

corenominal commented 12 years ago

Apologies for commenting on a closed issue, but I noticed that an initial tearing/vsync fix has been commited to cairo-compmgr. I have tested the fix and it seems to work well -- when watching http://www.youtube.com/watch?v=ZCPkOpMHB7g there is no visible tearing at all.

The commit, in case you wanted to check it out: http://git.tuxfamily.org/?p=ccm/cairocompmgr.git;a=commitdiff;h=efa4ceb97da501e8630ca7f12c99b1dce853c73e

I am loving compton and think it would be fantastic if this could be implemented as an option.

bytepossum commented 12 years ago

Sorry for yet another comment on closed issue, but I've found a patch which seems to implement vsync in Xfwm and thus, hopefully, enables tearing-free video playback:

https://bugzilla.xfce.org/show_bug.cgi?id=8898

I wonder if this or previously mentioned piece of code can be incorporated in Compton.

Janhouse commented 12 years ago

Compton with video tearing is kind of unusable. I hope this gets fixed at some point.

richardgv commented 12 years ago
  1. As chjj pointed out, Xrender itself has no support for VSync. People says the whole X server isn't actually aware of VSync, only the driver is.

  2. Despite that I know nothing about OpenGL and little about X, I've thought about 3 approaches after some research:

    1. Pure software method. Detect the refresh rate with Xrandr, then repaint with the pace. If the refresh rate is 60Hz, we paint at most 60 times per second.

      Pros: Easy to implement, low cost, saves resources by delaying event processing and repainting.

      Cons: sleep() may not accurately work (I've seen poll() not sleeping accurately); If the repaint starts at a particular time, maybe screen tearing will increase instead of decrease.

    2. Relying on DRM_IOCTL_WAIT_VBLANK. Simulating the xfwm4 patch corenominal pointed out.

      Cons: DRM_IOCTL_WAIT_VBLANK is reported to be "downright broken" on some chips in some cases; No documentation I could find; I have idea if it will work on proprietary drivers; the author says there's 10 pixel tearing area, and I don't know if it could get larger under specific situations (like very high load).

    3. Using OpenGL VSync functionalities. Simulating cairo-compmgr and Compipz.

      Cons: Might be driver-dependent, Compiz's VSync feature at least used to be broken on some chips; OpenGL wiki says "Your application's use of swap interval may be overridden by external, driver-specific configuration"; Little documentation; Uncertain if will conflict with the VSync feature of the driver like what chjj said; Linking to libGL.

      And I'm not quite sure what is the correct interface to use. SGI_swap_control, SGI_video_sync, or GLX_OML_sync_control? And bitSphere says mesa and nVidia/ATI drivers use different functions.

  3. The biggest problem is lack of documentation... I could try writing some code but there won't be a way for me test on every sort of GPUs. We don't have many developers, and I guess we are not rich enough to have many computers with different GPUs.
  4. My current suggestion is to check your driver for VSync support. The nVidia binary blob provides a "Sync to VBlank" option for me and I don't seem getting any tearing.
corenominal commented 12 years ago

I guess we are not rich enough to have many computers with different GPUs.

If you wanted to give option 1 a try, I have a bunch of different system I can test it on. Also, I think I could encourage a good few CrunchBang users to help with testing. Just a thought.

richardgv commented 12 years ago

If you wanted to give option 1 a try, I have a bunch of different system I can test it on. Also, I think I could encourage a good few CrunchBang users to help with testing. Just a thought.

Honestly I thought Plan 1 is the worst of all. :-) I might try to implement if you are interested, but not too soon -- it doesn't have the highest priority and I started getting busy recently.

Janhouse commented 12 years ago

I don't have much free time but if you need some help with testing or something else, I could try finding some time for it.

I can test it on laptops with Radeon X1200 (open source driver only) and Intel (3rd Gen Core processor Graphics Controller) video cards.

richardgv commented 11 years ago

Here you go, guys. Clone richardgv-dev branch and test! Read the commit log or usage text for information for how to enable VSync. All 3 methods need testing, but especially the DRM one -- it's entirely not tested.

When you try the software VSync remember to use --refresh-rate to specify your refresh rate. Probably the refresh rate detection isn't working.

If you have the the interest to further investigate if the painting time is correct, compile compton with:

make clean; CFLAGS='-DDEBUG_REPAINT' make

And compton will print out the detailed time of painting like this:

[     0:020020472 ] [     7.38 ] paint: 0x00c00352 0x00c00661 0x00c076eb 0x00c04cb8 0x00c0397a
[     0:020006796 ] [     7.40 ] paint: 0x00c00352 0x00c00661 0x00c076eb 0x00c04cb8 0x00c0397a
[     0:019991037 ] [     7.42 ] paint: 0x00c00352 0x00c00661 0x00c076eb 0x00c04cb8 0x00c0397a
[     0:019996693 ] [     7.44 ] paint: 0x00c00352 0x00c00661 0x00c076eb 0x00c04cb8 0x00c0397a
[     0:019993656 ] [     7.46 ] paint: 0x00c00352 0x00c00661 0x00c076eb 0x00c04cb8 0x00c0397a
[     0:020007497 ] [     7.48 ] paint: 0x00c00352 0x00c00661 0x00c076eb 0x00c04cb8 0x00c0397a
[     0:020004597 ] [     7.50 ] paint: 0x00c00352 0x00c00661 0x00c076eb 0x00c04cb8 0x00c0397a

The things in the first bracket is the time passed since last paint, in the format of [ SECONDS:NANOSECONDS ]; the second is the time passed since the program starts. If you see the interval is always N times of a fixed value (200, 000, 000 nanoseconds in the case above, as compton thinks my refresh rate is 50Hz -- but in fact it's 60Hz, the detection didn't work correctly), VSync is working.

This feature will not be available as a configuration file option before I'm sure it's working.

corenominal commented 11 years ago

Thank you for your continued work, @richardgv. The chipset on this machine (Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller) does not seem to support the DRM mode, but I have tested the sofware and opengl modes.

Visually, the opengl mode seems to be working better on this system, there is tearing but it happens at a static position on the screen. I guess it's a timing issue as to when compton starts because the tearing will be displayed at a different position on the screen, each time compton is invoked. If I am super lucky with my timing, it appears either at the very top or very bottom of screen and is only noticable when playing fullscreen video.

Using the software mode, the tearing is visable again in a single position on the screen, but moves slowley down until it reaches the bottom, then starts again from the top. I guess the timing is very slightly out?

I hope the above makes sense. Sorry I have not been able to provide any debug output, I will try and do some more testing on different systems tonight.

richardgv commented 11 years ago

@corenominal:

The chipset on this machine (Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller) does not seem to support the DRM mode

The DRM VSync should work for Intel drivers. I believe the driver use DRI in the kernel, right? Please check what error message are you receiving. "vsync_drm_init(): Failed to open device." indicates compton had troubles opening /dev/dri/card0, and please check if there's anything under /dev/dri. Other error messages or no error message generally indicates a bug in my code.

Visually, the opengl mode seems to be working better on this system, there is tearing but it happens at a static position on the screen. I guess it's a timing issue as to when compton starts because the tearing will be displayed at a different position on the screen, each time compton is invoked.

Oh, well, cairo-compmgr uses quite a similar method, and it does not have a tearing problem when we do? The only difference I could see is cairo-compmgr is probably using X DBE extension for rendering. Hmm, should we implement the same thing?

Using the software mode, the tearing is visable again in a single position on the screen, but moves slowley down until it reaches the bottom, then starts again from the top. I guess the timing is very slightly out?

There are two problems here that I could not understand:

  1. I've did a test here with 50Hz refresh rate specified in software VSync. There is an inaccuracy of tens of thousand nanoseconds per paint, possibly because of the time that compton's calculation takes, and inaccuracy in ppoll(), but this inaccuracy does not accumulate, so it should not cause the tearing line to move continuous in one direction (but it should cause the tearing line to go back and forth), unless you specified the wrong refresh rate -- which will probably make the tearing line move much more speedy than what you saw -- or compton does not count time in the same speed of your monitor.
  2. Even if we have a timing issue in the program, I imagine the tearing line should disappear after it goes over the bottom edge of the screen, instead of rotating instantly.

And at last, I have no luck reproducing any tearing, still. My knowledge about the whole thing is... Close to none. Before I read this issue report, I had no idea what VSync is. When I neither have sufficient knowledge nor could actually see and test about this problem, I'm afraid you can't expect much from me. Let's hope chjj could spot what's wrong in my code.

Janhouse commented 11 years ago

Device is 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) on Macbook Air running ArchLinux Linux janhouse 3.6.0-1-ARCH #1 SMP PREEMPT Mon Oct 1 20:51:05 CEST 2012 x86_64 GNU/Linux

$ ./compton --vsync sw --refresh-rate 60

In sw mode it is tearing in different place each time I start compton. If I start it at the right time it is hard to see tearing in VLC but I see it in http://www.youtube.com/watch?v=ZCPkOpMHB7g

Same command with debugging mode:

[     0:016670824 ] [    11.98 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061b1f6 0x0061b264 0x006104b4 0x00615165
[     0:016663557 ] [    12.00 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061b1f6 0x0061b264 0x006104b4 0x00615165
[     0:016659790 ] [    12.01 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061b1f6 0x0061b264 0x006104b4 0x00615165
[     0:016679815 ] [    12.03 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061b1f6 0x0061b264 0x006104b4 0x00615165
[     0:016661141 ] [    12.05 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061b1f6 0x0061b264 0x006104b4 0x00615165
[     0:033333099 ] [    12.08 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061b1f6 0x0061b264 0x006104b4 0x00615165
[     0:033365424 ] [    12.11 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061b1f6 0x0061b264 0x006104b4 0x00615165
[     0:016659622 ] [    12.13 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061b1f6 0x0061b264 0x006104b4 0x00615165
[     0:033304886 ] [    12.16 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061b1f6 0x0061b264 0x006104b4 0x00615165
[     0:016677879 ] [    12.18 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061b1f6 0x0061b264 0x006104b4 0x00615165
[     0:016714321 ] [    12.20 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061b1f6 0x0061b264 0x006104b4 0x00615165

$ ./compton --vsync opengl

I see tearing

With debugging:

[     0:016460135 ] [     5.12 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061af10 0x0061af7e 0x006104b4 0x00615165
[     0:016680112 ] [     5.14 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061af10 0x0061af7e 0x006104b4 0x00615165
[     0:022602128 ] [     5.16 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061af10 0x0061af7e 0x006104b4 0x00615165
[     0:017290292 ] [     5.18 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061af10 0x0061af7e 0x006104b4 0x00615165
[     0:010186604 ] [     5.19 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061af10 0x0061af7e 0x006104b4 0x00615165
[     0:020854538 ] [     5.21 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061af10 0x0061af7e 0x006104b4 0x00615165
[     0:012569494 ] [     5.22 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061af10 0x0061af7e 0x006104b4 0x00615165
[     0:033688256 ] [     5.26 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061af10 0x0061af7e 0x006104b4 0x00615165
[     0:016036658 ] [     5.27 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061af10 0x0061af7e 0x006104b4 0x00615165
[     0:016708235 ] [     5.29 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061af10 0x0061af7e 0x006104b4 0x00615165

$ ./compton --vsync drm

I see tearing

And with debugging:

[     0:016664764 ] [    10.00 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x0061541d 0x00600d38 0x0061a6e2 0x00615165 0x0061a694 0x006104b4
[     0:016689692 ] [    10.01 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x0061541d 0x00600d38 0x0061a6e2 0x00615165 0x0061a694 0x006104b4
[     0:016641894 ] [    10.03 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x0061541d 0x00600d38 0x0061a6e2 0x00615165 0x0061a694 0x006104b4
[     0:033361276 ] [    10.06 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x0061541d 0x00600d38 0x0061a6e2 0x00615165 0x0061a694 0x006104b4
[     0:016673573 ] [    10.08 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x0061541d 0x00600d38 0x0061a6e2 0x00615165 0x0061a694 0x006104b4
[     0:016663371 ] [    10.10 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x0061541d 0x00600d38 0x0061a6e2 0x00615165 0x0061a694 0x006104b4
[     0:033328853 ] [    10.13 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x0061541d 0x00600d38 0x0061a6e2 0x00615165 0x0061a694 0x006104b4
[     0:033339222 ] [    10.16 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x0061541d 0x00600d38 0x0061a6e2 0x00615165 0x0061a694 0x006104b4
[     0:016658948 ] [    10.18 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x0061541d 0x00600d38 0x0061a6e2 0x00615165 0x0061a694 0x006104b4
[     0:016677822 ] [    10.20 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x0061541d 0x00600d38 0x0061a6e2 0x00615165 0x0061a694 0x006104b4
[     0:016668543 ] [    10.21 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x0061541d 0x00600d38 0x0061a6e2 0x00615165 0x0061a694 0x006104b4
richardgv commented 11 years ago

Ah, I forgot to say, thanks for your tests. :-)

@Janhouse:

The good thing is I saw under both the sw mode and the drm mode, compton is painting with the correct timing. The opengl mode test result looks somewhat incorrect, but, hmm, it's working in both in corenominal's and my tests.

The bad thing is, looks like by controlling the timing of painting I only (mostly) successfully sticked the tearing line to a fixed place on the screen instead of removing it. Hmm, I have no idea what's wrong...

richardgv commented 11 years ago

Alright, another attempt: Double buffering, stolen from cairo-compmgr. Please clone from richardgv-dev branch and run compton with a VSync method and --dbe, and test if the tearing changes somehow. (But I'm interested in the result when --dbe alone is enabled, too.) Although I don't think double buffering will cause a huge drop in performance, I still would recommend you guys to check for any possible performance issue caused by double buffering.

kwin does not seem supporting VSync at all in its XRender mode, and I'm unsuccessful in finding the VSync code in mutter. If double buffer fails to work... Are you guys aware of any other compositing window manager that supports VSync and uses XRender as backend?

Janhouse commented 11 years ago

A quick test didn't show any improvements but then I started googling and found that many people have the tearing problem with those new Intel graphics cards. I installed some git versions for those drivers and will test if something changes after I reboot. Will post how it goes after I test it.

richardgv commented 11 years ago

Now it's the real problem why apparently VSync in cairo-compmgr is working for corenominal, but I cloned its VSync and it did not work... Is there still a tearing line appearing in a fixed place?

If you have some extra time, I hope you could do some tests to help the diagnostics:

  1. Try the git version of cairo-compmgr and see if it's tearing-free. I personally could not get the version working without segfault, somehow.
  2. Try commenting out line 1704 of ./src/compton.c, which is:
    XdbeSwapBuffers(dpy, &swap_info, 1);

Then compile, and run with:

./compton --dbe --vsync sw --refresh-rate 60

If everything goes right, all your windows will disappear, with only the root window (wallpaper) left. (Then you use Ctrl-C to terminate compton blindly.) This verifies if double buffering is actually working.

I'm still not sure about the process of how things are rendered to monitor, and why people are not able to stop tearing by starting compton in a specific range of time between refreshes with software VSync...

If I could not find a better solution I might have to let compton wait for one frame before painting so the tearing line, with the best luck, might stick to somewhere pretty close to the top of the screen. And that will still not work for software VSync...

Update: Ah, I saw this, which indeed probably points to a driver issue instead of a compositing window manager issue: http://www.phoronix.com/scan.php?page=news_item&px=MTIxMTM

But you see absolutely no tearing if compton is not running, right? Even with the unaccelerated x11 video output mode?

richardgv commented 11 years ago

Another update:

Please clone from richardgv-dev and check if the painting-on-overlay support added in 049621bed7 helps. Please test both --paint-on-overlay and --paint-on-overlay --dbe (of course, enable --vsync, too). Although I don't think they are much related, it at least simulates cairo-compmgr better.

tserhii-gh commented 11 years ago

Latest richardgv-dev, trying all variants:

xubuntu 12.10 nvidia 310.14 (card GT240)

--vsync opengl --dbe --vsync opengl --dbe --paint-on-overlay --vsync opengl --paint-on-overlay

top half screen tearing

--vsync sw --refresh-rate 60 --dbe --vsync sw --refresh-rate 60 --dbe --paint-on-overlay --vsync sw --refresh-rate 60 --paint-on-overlay

tearing goes from top of screen to bottom with some delay

richardgv commented 11 years ago

Very well then. I guess I've done pretty much what I could do, and eventually I have to ask somebody else. Let's hope the Xorg guys will bring us something impressive: http://lists.x.org/archives/xorg/2012-October/054996.html

Meanwhile, please check the OpenGL settings and XVideo settings in nvidia-settings, and enable their "Sync To VBlank", see if things changes.

Update:

Ah, I thought about a thing! Probably I have fundamentally misunderstand VSync. Will try to implement later.

richardgv commented 11 years ago

Ah, GitHub, you are way too smart again!

Now please clone from richardgv-dev branch and test. I hope this commit could at least have some positive effects. The software VSync does not work as VSync, I believe, so it has been turned into --sw-opti (Software optimization), the syntax of the rest stays the same.

tserhii-gh commented 11 years ago

With --vsync opengl --sw-opti options, even in video players (vdpau, xv) and flash, it's tears only on top of screen where my panel situated ^^. Great work:) It's interesting the same problem in Kwin(4.8,4.9.1,4.9.2)https://bugs.kde.org/show_bug.cgi?id=307965

richardgv commented 11 years ago

Thanks for your test, and your link. So all my efforts result in a situation not much better than the Xfce patch? Now I truly have no idea how to get rid of the tearing...

Have you actually tried --dbe after the commit, then? It would be depressing if --dbe --vsync opengl still has the tearing issue. Moving line 1727 in src/compton.c might slightly move the line closer to the top in non-DBE mode, but I want to see how DBE works firstly.

Kwin, when using XRender as backend, does not seem to even have VSync; its OpenGL backend probably uses double buffering (or triple buffering, etc.), which could have better performance than the X DBE double buffering, so if even Kwin with OpenGL backend is doing tearing... Oh, well, let's see what reply my question posted on Xorg mailing list will receive firstly before trying to decide anything.

By the way, haven't I warned that --vsync XXX and --sw-opti shouldn't be used together in the commit log? Effectively it generally causes no additional speed benefits but frame dropping.

By the way 2, have you actually looked into nvidia-settings as I recommended in one of the previous replies?

tserhii-gh commented 11 years ago

Oops) nvidia-settings all vsync(xv, opengl)

--sw-opti (with / without dbe)

tearing whole screen

--vsync opengl (with / without dbe)

top of screen trearing, 10...18 px i think

richardgv commented 11 years ago

Oh, 18px is big enough, even larger than that of the Xfce patch. Truly mysterious why I don't see tearing even if I turn all VBlank stuffs off. Oh, you have "Allow flipping" enabled in nvidia-settings, right? It could be useful for double buffering, I guess. And are you experiencing the tearing on other window managers? If you could find a tear-free one, I might be able to get something from its code.

By the way, somebody suggested VSync in nvidia-drivers does not work if the Performance level is 0, and adjusting the "PowerMizer settings" in the GPU panel of nvidia-settings fixed the issue for him. The link, among other possible fixes: http://askubuntu.com/questions/125245/how-do-i-stop-video-tearing-nvidia-prop-driver-non-compositing-window-manager

tserhii-gh commented 11 years ago

Yes, "Allow flipping" option is enabled by default on new nvidia drivers.

Tear-free for me mutter / muffin (gnome-shell / cinnamon)

but i have some lag when dragging windows: window follow mouse pointer too slow (with some delay), this starts from gnome 3.5, and its awful in 3.6, same on cinnamon 1.*, windows looks so heavy)))

Also with compiz i had no tearing.

tritonas00 commented 11 years ago

Thank you for your great work!

Intel gma 3150 with --vsync opengl (archlinux - xf86-video-intel 2.20.12 and mesa 9.0)

Finally my netbook runs almost tear-free with openbox and compton ! Also no tearing in videos !

I say almost because I only have tearing at the very top of the screen.

I will test it in my desktop with nvidia 9600 and let you informed.

corenominal commented 11 years ago

Sorry for the delay in providing feedback, work has been manic. Anyhow, nice job work, @richardgv, and thank you! Using compton --dbe --vsync opengl works really well, the tearing line is pinned to the top of my screen and during normal operation is completely invisible. Brilliant!

richardgv commented 11 years ago

@funeral1988:

Also with compiz i had no tearing.

Yep, OpenGL buffer swap could be faster than X DBE buffer swap...

Tear-free for me mutter / muffin (gnome-shell / cinnamon)

Mutter uses clutter too much that makes its code harder to read. Well, I will see if I could get something.

Update: Clutter is OpenGL based, as far as I can see. It never actually mentions "XRender". So, we probably can't borrow much from mutter this time.

@tritonas00: Thanks for you feedback. :-)

@corenominal: Thanks. Yeah, a tearing line on the top, that cannot be removed... Has cairo-compmgr successfully fixed all the tearing issue?

tserhii-gh commented 11 years ago

@richardgv: good to hear), u already did great job! thx

Mutter uses clutter too much that makes its code harder to read. Well, I will see if I could get something.

the most important issue after i stop using gnome-shell and cinnamon its delayed movement windows (on gnome 3.6 its terrible) and i can't find any information about that, its nvidia blob's problem or not,i don't know, and its little scares me that u'll using some peace of code from mutter project.

richardgv commented 11 years ago

@funeral1988:

Huh, clutter looks entirely OpenGL based. Most likely we cannot port its rendering code to XRender-based compton.

Right now my estimation is the VBlank interval is too short and XRender/X DBE is not painting fast enough (or schedules painting of compton after some other tasks), causing tearing on the top of the screen, while OpenGL, with direct access to the driver, does this much faster. But it's just my estimation.

the most important issue after i stop using gnome-shell and cinnamon its delayed movement windows (on gnome 3.6 its terrible) and i can't find any information about that, its nvidia blob's problem or not,i don't know, and its little scares me that u'll using some peace of code from mutter project.

It could be an issue of the performance of your GPU. We had multiple reports about delayed window movements, and they point to GPU performance from appearance. (At least, they said it went away after I reduced painting requests compton sends and the painting region.) Maybe mutter is just doing too much abundant drawing on the screen.

OrdinaryMagician commented 11 years ago

After cloning from the richardgv-dev branch, with no parameters other than --vsync opengl I can confirm that:

bytepossum commented 11 years ago

I just tested the latest build of richardgv-dev branch with Intel x3100 and 2.20.8 driver on Fedora 17 and see the following:

richardgv commented 11 years ago

Well, I should have carefully read the Xfwm4 VSync patch earlier... I pushed another commit, fb2ca16cb8, to richardgv-dev, that may or may not move the tearing line upward. Please test if the commit helps in some ways (or make things worse in some ways). There's a commandline switch added, --vsync-aggressive, that may have either slightly positive or very negative effects on VSync, and please also test that. (The commit improves VSync even without --vsync-aggressive, so please test both with and without --vsync-aggressive.)

@OrdinaryMagician:

Huh, thank you. :-)

There's practically no drops in performance both on games and video playback.

Well, if you turn off OpenGL "Sync to VBlank" in nvidia-settings, and run glxgears with and without compton running, I believe you will observe the difference from the FPS. The performance does drop anyway...

There are no sudden frame drops.

If you are talking about frames being skipped over when compton is running (or you mean FPS drops?), then yes, compton's VSync is known (theoretically) to have the possibility of causing frame drops (we may reduce this in a certain degree if we use multithreading), but the frame drops are barely noticeable, as without supernatural power, human eyes can't read 60 frames per second.

X server CPU usage stays around 1~2 percent.

Ah, that doesn't look bad. :-)

@glesik: Ah, thanks. And 150px is moderately long to be annoying for you, I bet? Could you please test if the latest commits help?

tearing zone appears at ~150px from the top, scrolls up and disappears for ~10s, then everything repeats;

Huh, I really have no idea why that thing would move...

OrdinaryMagician commented 11 years ago

@richardgv

Well, if you turn off OpenGL "Sync to VBlank" in nvidia-settings, and run glxgears with and without compton running, I believe you will observe the difference from the FPS. The performance does drop anyway...

Yes, there's a drop from 19765 to 13698 FPS, but I do believe it's not practically noticeable. Besides, making the GPU do more work than it needs isn't good either way.

If you are talking about frames being skipped over when compton is running (or you mean FPS drops?), then yes, compton's VSync is known (theoretically) to have the possibility of causing frame drops (we may reduce this in a certain degree if we use multithreading), but the frame drops are barely noticeable, as without supernatural power, human eyes can't read 60 frames per second.

I was actually talking about cases where suddenly the framerates would drop below 1 FPS for some seconds causing the screen to become garbled with excessive tearing. It was the main reason I had stopped using composition in the first place.

Actually, it seems to still happen, but more softly. I was playing Dishonored last night, fullscreen, and after 20 minutes I noticed the framerate was quite low (but not to the point of becoming a "slideshow"), alt-tabbing and checking the task manager showed that X was using about 15% CPU, and didn't stop until I restarted compton.

richardgv commented 11 years ago

@OrdinaryMagician:

Hey, do you actually have a tearing issue and needs VSync? If you have the issue, please read the top part of my last comment.

Yes, there's a drop from 19765 to 13698 FPS, but I do believe it's not practically noticeable. Besides, making the GPU do more work than it needs isn't good either way.

6,000 FPS drop, huh...

I was actually talking about cases where suddenly the framerates would drop below 1 FPS for some seconds causing the screen to become garbled with excessive tearing. It was the main reason I had stopped using composition in the first place.

Actually, it seems to still happen, but more softly. I was playing Dishonored last night, fullscreen, and after 20 minutes I noticed the framerate was quite low (but not to the point of becoming a "slideshow"), alt-tabbing and checking the task manager showed that X was using about 15% CPU, and didn't stop until I restarted compton.

Well, compton is known to use more CPU than xcompmgr, but it may stress the GPU less. I personally almost never play games on Linux, and I don't know the "frame dropping" thing.

X is using 15% CPU? Well, and the rest 85% are all occupied or not? You have to figure out where the bottleneck is, the CPU or the GPU. X using 15% CPU is not too surprising, anyhow. I've seen X using 20%+ during some activities without compton running.

So are you experiencing frame dropping with other compositing window managers? xcompmgr, too?

2 users already reported compton is causing high CPU usage on the X process after long time of usage, but it's so hard to reproduce and debug... Link: https://github.com/chjj/compton/issues/50#issuecomment-9921296

I may add a feature that let compton stop compositing if it detects a fullscreen window later, also.

OrdinaryMagician commented 11 years ago

@richardgv

Hey, do you actually have a tearing issue and needs VSync?

I can't quite understand what you've said, sorry.

6,000 FPS drop, huh...

As long as the framerate is still much higher than the screen refresh rate, it doesn't matter much.

X is using 15% CPU? Well, and the rest 85% are all occupied or not? You have to figure out where the bottleneck is, the CPU or the GPU. X using 15% CPU is not too surprising, anyhow. I've seen X using 20%+ during some activities without compton running.

Well, the rest of CPU was unoccupied by then.

So are you experiencing frame dropping with other compositing window managers? xcompmgr, too?

I run Openbox standalone. Haven't actually tested other WMs or composite managers and I guess I'm too lazy to do so.

I may add a feature that let compton stop compositing if it detects a fullscreen window later, also.

That sounds nice, I'm looking forward to it.

richardgv commented 11 years ago

@OrdinaryMagician:

I can't quite understand what you've said, sorry.

Sorry, my English isn't great. I meant, if you do see tearing when playing videos with compton running, please follow my advices in the next-to-last reply, to pull and build from richardgv-dev branch right now and test if my latest commits help, and test if --vsync-aggressive switch has some effect over the position of the tearing line. If you didn't meet the tearing issue, please discuss in #50 instead. This issue report primarily is for discussing about the tearing issue.

As long as the framerate is still much higher than the screen refresh rate, it doesn't matter much.

A frame in a game takes much more resources than a frame in glxgears. 6,000 FPS is roughly 1/3 of your total FPS, so it generates a 33% performance penalty, which could be troublesome when you are playing a game with higher requirement on GPU.

Well, the rest of CPU was unoccupied by then.

Then your bottleneck is GPU? Then I guess I can't do much. compton is almost doing minimal painting, I suppose. I have no idea how the driver and the graphic card are working, and I don't know where could still be optimized on the GPU side.

OrdinaryMagician commented 11 years ago

@richardgv ah... sorry, I'll go there then.

tritonas00 commented 11 years ago

No tearing on my nvidia 9600 (archlinux, compton --vsync opengl)

Great ! Can i ask, when are u going to move the code to master branch ?

Thanks!

Janhouse commented 11 years ago

I get almost no tering with --vsync opengl --sw-opti with 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09).

The top part of the video is tearing in fullscreen Youtube (flash) videos but it is not that annoying as it was when it happened in the middle of the screen. And it is not tearing in VLC anymore so I am pretty happy with the results. :)

Oh and in one moment the whole UI started lagging and became really unresponsive and went back to normal only when I killed compton. Not sure if something is leaking but I just wanted to mention this in case someone else notices it. It happened only once so far so no clue where it came from and how to reproduce it.

richardgv commented 11 years ago

@tritonas00:

Ah, awesome, thank you. :-)

Great ! Can i ask, when are u going to move the code to master branch ?

A series of aggressive changes has been pushed into richardgv-dev branch recently, and it is my plan to review the patches in #59 and merge it later, which is going to be a risky change. And as we have no formal release for now, many distros are pulling from the master branch. Overall, it's not too likely that the richardgv-dev branch is to be merged into master really soon, sorry.

@Janhouse:

Ah, cool, thanks. :-)

The top part of the video is tearing in fullscreen Youtube (flash) videos but it is not that annoying as it was when it happened in the middle of the screen.

Have you tried the --vsync-aggressive flag added to richardgv-dev branch yesterday? I will remove that if people report it has no effect or negative effects.

Oh and in one moment the whole UI started lagging and became really unresponsive and went back to normal only when I killed compton. Not sure if something is leaking but I just wanted to mention this in case someone else notices it. It happened only once so far so no clue where it came from and how to reproduce it.

You are 4th or the 5th person complaining about the mysterious slowdown. Well, I will finish my serious (and boring) work today, look into the more annoying #59 tomorrow, and I may only have time after tomorrow to try to let compton continuously run until I could reproduce this issue.

Janhouse commented 11 years ago

That slowdown bug happens only after some long time and in my case when Firefox and Chrome is open (each with about 30 open tabs). RAM is not full and X and compton is not even in top 5 of ram usage list.

richardgv commented 11 years ago

@Janhouse:

Thank you. :-) I've pushed a (again, possible) fix for the problem to richardgv-dev branch. The whole story and the things I want to say to anybody who is encountering the issue is here: https://github.com/chjj/compton/issues/50#issuecomment-10035751

If X is using not much memory, it could indicate the chance of a Picture leak is not high, at least.

bytepossum commented 11 years ago

For me --vsync-aggressive only made things worse: the tearing zone now slowly scrolls up all across the screen for ~12 seconds (pretty much like with --vsync none). But I think that clarifies a little the behavior I described before: with --vsync opengl the zone is moving the same way, but tearing itself is visible only within top ~150px.

By the way, both opengl and drm have the same result now: tearing scrolls but is visible only on the top.

richardgv commented 11 years ago

@glesik:

For me --vsync-aggressive only made things worse: the tearing zone now slowly scrolls up all across the screen for ~12 seconds (pretty much like with --vsync none). But I think that clarifies a little the behavior I described before: with --vsync opengl the zone is moving the same way, but tearing itself is visible only within top ~150px.

By the way, both opengl and drm have the same result now: tearing scrolls but is visible only on the top.

Thanks for testing. :-)

I wasn't expecting --vsync-aggressive to work at all. I just don't understand why the xfwm4 VSync patch uses that. Once I receive another negative report I will remove it.

I still couldn't comprehend why the tearing line would move in that way, but, well, it's pretty much the furthest I could get to in the VSync issue. Nobody is replying to my VSync question on xorg user mailing list. You probably have to bear the 150px tearing unless you switch to a OpenGL-based compositing window manager.

jersteth commented 11 years ago

Also I have thoroughly tested the latest version (I hope the correct one - git master). I am using via_chrome9 drivers, which are based on open source intel drivers and support dri/drm wait for vblank. Xfwm4 with tearing patch was "sort of" working, but stopped working after I recently upgraded webkitgtk. Compton solves tearing for me with this new webkit, so I switched.

compton --vsync=drm --dbe is giving me the best results (slight tearing in top 100 pixels in <1% of the time, no tearing in 90% of the time and top 20 pixels tearing in the rest of the time. vsync-aggressive is screwing things up. compton --vsync opengl slightly worse by=ut also works acceptable. compton --drm without --dbe is comparable. --paint-on-overlay doesn't seem to influence it either.

richardgv commented 11 years ago

@jeroenost:

Thank you for your tests, jeroenost!

I am using via_chrome9 drivers, which are based on open source intel drivers and support dri/drm wait for vblank.

Huh, sorry, but are you talking about xf86-video-openchrome, xf86-video-unichrome, the VIA Unichrome DRM module in kernel, the VIA broken proprietary drivers, or something else?

Xfwm4 with tearing patch was "sort of" working, but stopped working after I recently upgraded webkitgtk. Compton solves tearing for me with this new webkit, so I switched.

I don't really understand how webkit-gtk could be related to VSync in xfwm4...

Basically we use the same approach as the xfwm4 patch does (well, even a bit weaker), so they should have roughly the same effect.

compton --vsync=drm --dbe is giving me the best results (slight tearing in top 100 pixels in <1% of the time, no tearing in 90% of the time and top 20 pixels tearing in the rest of the time. vsync-aggressive is screwing things up. compton --vsync opengl slightly worse by=ut also works acceptable. compton --drm without --dbe is comparable. --paint-on-overlay doesn't seem to influence it either.

I'm glad to see it works acceptably on your system. :-) Huh, too bad I couldn't improve it further.

jersteth commented 11 years ago

Via has recently released open source drivers on http://linux.via.com.tw/support/downloadFiles.action I am using driver version 5.76.52.92-003-68680. They released source code for both module and xorg driver. The hardware acceleration is fine and quite performant. Some context: I am building an application where we display full screen video with a HTML5 overlay, rendered by webkitgtk with a transparant background. Up until recently I was using an old version of webkitgtk 1.6.3 with VLC for the video. For font anti aliassing with the background and some transparency effects, it is important I have compositing between the two windows. With VLC set to XVideo out on adaptor XV_TEXTURE (which has compositing), I never could get rid of tearing. I only managed to get rid of it by using VLC OpenGL output, in combination with xfwm4's tearing patch. Recently I had to upgrade webkit to a newer version (1.10.2) because of segfaults in the old webkit. I noticed tearing got terribly worse. That seems very unlogical, I know. I made a couple of theories. Perhaps webkit is also trying to use glxSwapBuffers or any other OpenGL vsync method. Another theory is that webkit 1.10.2 is using the gtk main loop a lot more for timers, leave less time and more inpredictable behaviour for scheduling timers. Either way, with xfwm4 tearing is, and with compton it's better. I didn't know about compton earlier, but I must say I like it. xfwm4 was way too much overhead and functionality. Compton is lighter. I will see if I can spend some time in the code to improve things.

What exactly is --paint-on-overlay supposed to do ? Because what I saw is that both with Intel and VIA drivers (comparing both has learned me that VIA bases their drivers at least partly on Intel code) , there are two XVideo adaptors. The first one, XV_SWOV is actually using an overlay to display video and is by design tear-free (totally). It doesn't composite though. The second one, XV_TEXTURE has compositing but is suffering from tearing. I would like to create an approach where we do the compositing ourselves, then use XV_SWOV to display the end result.

"xvinfo" gives more info on both.

I will look into the compton code when I have some time.

jersteth commented 11 years ago

Further testing today has showed me that I get best, almost perfect results by

--sw-opti and --vsync-aggressive are making tearing slightly worse.

This is really nice work. Thanks a lot.

richardgv commented 11 years ago

Via has recently released open source drivers on http://linux.via.com.tw/support/downloadFiles.action I am using driver version 5.76.52.92-003-68680. They released source code for both module and xorg driver. The hardware acceleration is fine and quite performant.

Ah, thanks for info, I didn't know that. I had a few years of experience with a VIA UniChrome Pro IGP and the openchrome driver, and it definitely wasn't the greatest driver I've seen. Glad to see VIA is back working on this.

Some context: I am building an application where we display full screen video with a HTML5 overlay, rendered by webkitgtk with a transparant background. Up until recently I was using an old version of webkitgtk 1.6.3 with VLC for the video. For font anti aliassing with the background and some transparency effects, it is important I have compositing between the two windows. With VLC set to XVideo out on adaptor XV_TEXTURE (which has compositing), I never could get rid of tearing. I only managed to get rid of it by using VLC OpenGL output, in combination with xfwm4's tearing patch. Recently I had to upgrade webkit to a newer version (1.10.2) because of segfaults in the old webkit. I noticed tearing got terribly worse. That seems very unlogical, I know. I made a couple of theories. Perhaps webkit is also trying to use glxSwapBuffers or any other OpenGL vsync method. Another theory is that webkit 1.10.2 is using the gtk main loop a lot more for timers, leave less time and more inpredictable behaviour for scheduling timers.

Seemingly, WebKit does have VSync code in ./platform/graphics/chromium/cc/CCFrameRateController.*, but it's in the chromium-specific graphic part. I don't really know whether GTK+/cairo does some VSync.

I will look into the compton code when I have some time.

Cool. :-) vsync_drm_wait() and vsync_opengl_init() are the functions that waits for VSync.

What exactly is --paint-on-overlay supposed to do ?

--paint-on-overlay lets compton paint on the X Composite overlay window. X Composite protocol specification describe this window as:

Version 0.3 of the protocol adds the Composite Overlay Window, which provides compositing managers with a surface on which to draw without interference. This window is always above normal windows and is always below the screen saver window. It is an InputOutput window whose width and height are the screen dimensions. Its visual is the root visual and its border width is zero. Attempts to redirect it using the composite extension are ignored. This window does not appear in the reply of the QueryTree request. It is also an override redirect window. These last two features make it invisible to window managers and other X11 clients. The only way to access the XID of this window is via the CompositeGetOverlayWindow request. Initially, the Composite Overlay Window is unmapped.

As far as I know, most compositing window managers (except xcompmgr and some of its derivatives) paints to this window by default. X.org probably is actually copying the content from the composite window back to the root window, but I'm not too sure about the details in implementation of the composite window.

Further testing today has showed me that I get best, almost perfect results by

  • disabling kernel preemption (CONFIG_PREEMPT) (keeping CONFIG_PREEMPT_VOLUNTARY=y). I haven't tried changing the latter to N as well.
  • compton --vsync drm --paint-on-overlay paint-on-overlay is eliminating the sporadic tearing I saw around 50-100px from the top. Now it seems only <10px from the top and very very seldom (fast moving action scenes where the camera swipes left/right)

Thanks. :-) Would you mind if I put this on wiki as your experience might be helpful for others?

--sw-opti and --vsync-aggressive are making tearing slightly worse.

--sw-opti should not be used with --vsync, by the way. --vsync essentially does --sw-opti's job already. I forgot to mention that in man page.