Composited video using nvidia cards (tested on ion and quadro nvs, either nouveau or the closed-source driver) shows a screen tearing artifacts, in non-composited window managers, no matter if the vblank sync configuration is enabled.
I experimented with glXSwapIntervalEXT and it doesn't improve the tearing issue.
I'm wondering if we should add some kind of vblank handling as cogl does: https://git.gnome.org/browse/cogl/tree/cogl/winsys/cogl-winsys-glx.c#n1741
Created attachment 206071 [details] Update the texture _only_ when it is going to be painted.
Created attachment 206073 [details] Call glXSwapInterval(1) if available
Created attachment 206086 [details] opengl trace of a webkit1 session The FB Context is created without double buffer!
Comment on attachment 206073 [details] Call glXSwapInterval(1) if available View in context: https://bugs.webkit.org/attachment.cgi?id=206073&action=review > Source/WebCore/platform/graphics/glx/GLContextGLX.cpp:155 > + glXSwapInterval = reinterpret_cast<PFNGLXSWAPINTERVALSGIPROC>(glXGetProcAddress(reinterpret_cast<const GLubyte*>("glXSwapIntervalSGI"))); Something like this belongs in OpenGLShims. > Source/WebCore/platform/graphics/glx/GLContextGLX.cpp:253 > + if (m_window) { > + bool ret = glXMakeCurrent(sharedX11Display(), m_window, m_context); > + if (glXSwapInterval) > + glXSwapInterval(1); > + XSync(sharedX11Display(), False); > + return ret; > + } Does it make sense to call this even if we are running under a composited window manager?
You've got a couple different patches here, but none of them are up for review. If you want them reviewed, I recommend making this patch a meta bug and creating one dependent bug for each patch.
(In reply to comment #7) > You've got a couple different patches here, but none of them are up for review. If you want them reviewed, I recommend making this patch a meta bug and creating one dependent bug for each patch. I didn't ask for review because those patches don't solve the problem. I uploaded them a as reference of what I have tried.
I am having trouble with both WebKit and direct gst-launch. I have an Intel 915 and I tried with GStreamer 1.0.4, 1.0.7 and today's master with same tearing result. I am adding CCing Sebastian in case he can shed some light.
If you see tearing it most probably is caused by doing rendering during vsync. To get around that you should synchronize all drawing operations with vsync, i.e. make sure that the drawing operation is started and finished before the next vsync. Something like glXSwapInterval(1) should do that though.
Ideally you would have a render loop that renders everything right before the vsync, and separate to that the uploading of the textures. So the render loop would always see finished textures, and always takes the latest of all textures and then immediately renders them. This is also the way how we want to change the GStreamer video sinks in the future.
mozilla related info: https://bugzilla.mozilla.org/show_bug.cgi?id=689419
Gtk+-3.8 offers API for vblank sync https://developer.gnome.org/gdk3/stable/gdk3-GdkFrameClock.html Cogl has it's own means for vblank sync https://git.gnome.org/browse/cogl/tree/cogl/winsys/cogl-winsys-glx.c#n1880
This issue is fixed when using GTK+ 3.8, likely due to support for the Window Manager frame synchronization protocol. https://mail.gnome.org/archives/gtk-list/2013-March/msg00019.html I'll upload the patch that bumps the Jhbuild versions of the GTK+ and Glib packages.
(In reply to comment #14) > I'll upload the patch that bumps the Jhbuild versions of the GTK+ and Glib packages. Err, GTK+ and Gdk-Pixbuf.
Created attachment 207754 [details] Patch
Comment on attachment 207754 [details] Patch Clearing flags on attachment: 207754 Committed r153518: <http://trac.webkit.org/changeset/153518>
All reviewed patches have been landed. Closing bug.
Re-opened since this is blocked by bug 119386
(In reply to comment #19) > Re-opened since this is blocked by bug 119386 Rolling out the Jhbuild dependency bump. The bump wasn't required by the layout tests and is causing problems with the increased Pando dependency, but do note that the fix is still valid - when using GTK+ >= 3.8, the screen tearing is no longer present.
Closing as fixed as per comment #20.
(In reply to comment #21) > Closing as fixed as per comment #20. I applied the patch and compiled WebKit with "Tools/Scripts/build-webkit --gtk --enable-webkit2 --disable-gtk-doc --enable-introspection=no --no-svg" and run the example with "Tools/Scripts/run-launcher --gtk --enable-accelerated-compositing=TRUE url" in GNOME Classic and I still can see the tearing. It's less noticeable, but it is still there. I think we should reopen this.
Reopening.
(In reply to comment #22) > (In reply to comment #21) > > Closing as fixed as per comment #20. > > I applied the patch and compiled WebKit with "Tools/Scripts/build-webkit --gtk --enable-webkit2 --disable-gtk-doc --enable-introspection=no --no-svg" and run the example with "Tools/Scripts/run-launcher --gtk --enable-accelerated-compositing=TRUE url" in GNOME Classic and I still can see the tearing. It's less noticeable, but it is still there. I think we should reopen this. Confirming using a Nvidia gpu, the tearing is still there.
(In reply to comment #24) > Confirming using a Nvidia gpu, the tearing is still there. Can you guys confirm whether you are seeing this with the version of GTK+ that reported to have fixed this issue?
(In reply to comment #25) > (In reply to comment #24) > > > Confirming using a Nvidia gpu, the tearing is still there. > > Can you guys confirm whether you are seeing this with the version of GTK+ that reported to have fixed this issue? $ jh run ldd WebKitBuild/Debug/.libs/libwebkitgtk-3.0.so.0.19.3 | grep libgtk libgtk-3.so.0 => /home/sicom/WebKit/WebKitBuild/Dependencies/Root/lib/libgtk-3.so.0 (0xb2b16000) $ ls -la /home/sicom/WebKit/WebKitBuild/Dependencies/Root/lib/libgtk-3.so.0 lrwxrwxrwx. 1 sicom sicom 19 Aug 4 12:17 /home/sicom/WebKit/WebKitBuild/Dependencies/Root/lib/libgtk-3.so.0 -> libgtk-3.so.0.800.2 libgtk+-3.8.2
(In reply to comment #24) > (In reply to comment #22) > > I applied the patch and compiled WebKit with "Tools/Scripts/build-webkit --gtk --enable-webkit2 --disable-gtk-doc --enable-introspection=no --no-svg" and run the example with "Tools/Scripts/run-launcher --gtk --enable-accelerated-compositing=TRUE url" in GNOME Classic and I still can see the tearing. It's less noticeable, but it is still there. I think we should reopen this. > > Confirming using a Nvidia gpu, the tearing is still there. What drivers are you using? FWIW, I got no tearing after upgrading to 3.8 and using the Nvidia blob.
(In reply to comment #27) > (In reply to comment #24) > > (In reply to comment #22) > > > I applied the patch and compiled WebKit with "Tools/Scripts/build-webkit --gtk --enable-webkit2 --disable-gtk-doc --enable-introspection=no --no-svg" and run the example with "Tools/Scripts/run-launcher --gtk --enable-accelerated-compositing=TRUE url" in GNOME Classic and I still can see the tearing. It's less noticeable, but it is still there. I think we should reopen this. > > > > Confirming using a Nvidia gpu, the tearing is still there. > > What drivers are you using? I'm using the closed nvidia blob as well. > > FWIW, I got no tearing after upgrading to 3.8 and using the Nvidia blob.
I've retested this yesterday. With a fresh build and using the default set of dependencies (i.e. GTK+ 3.6) I got no tearing (even though I experienced it about a month back, when upgrading to GTK+ 3.8 fixed the issue for me). I've tested with both nouveau and the Nvidia blob drivers on an Nvidia system, and with the i915 driver on an Intel system. I was using Ubuntu 13.04 in all cases. Can anyone else still reproduce this? I'm hoping this has been somehow fixed recently by changes in the WebKit tree.
To expand on comment #29, I also tested a build of a month-old revision (from around the time when r153518 landed -- comment #17), and while I was able to reproduce the tearing back then, I couldn't reproduce it this time. This is turning quite odd on my part, so I'd like to gather information about what software people still experiencing the problem are using. Specifically, I'm interested in the following: - distribution being used, along with the version, - the X system version being used if it differs from the version the distribution provides by default, - the graphics driver being used, along with the version. With this information I would hopefully be able to (again) reproduce the tearing on my hardware. Thanks in advance!
(In reply to comment #30) Using r157159, GTK+ 3.8.2, debug build, GtkLaunch, and I still see the tearing in scenes with high movement. > To expand on comment #29, I also tested a build of a month-old revision (from around the time when r153518 landed -- comment #17), and while I was able to reproduce the tearing back then, I couldn't reproduce it this time. > > This is turning quite odd on my part, so I'd like to gather information about what software people still experiencing the problem are using. > > Specifically, I'm interested in the following: > - distribution being used, along with the version, Fedora17 > - the X system version being used if it differs from the version the distribution provides by default, xorg-x11-server-Xorg-1.12.4-7.fc17.i686 > - the graphics driver being used, along with the version. NVIDIA Driver version 304.88 > > With this information I would hopefully be able to (again) reproduce the tearing on my hardware. Thanks in advance!
Confirming what Zan Dobersek said in comment #20: Using Fedora20, with xorg-x11-server-Xorg-1.14.4-5.fc20.i686 gtk3-devel-3.10.5-1.fc20.i686 nvidia version 304.108 And there is _NOT_ tearing. Recent developments in Xorg and GTK+ added frame displaying control, avoiding the tearing effect. Hence, I'm closing this bug.
(In reply to comment #32) > Confirming what Zan Dobersek said in comment #20: > > Using Fedora20, with > > xorg-x11-server-Xorg-1.14.4-5.fc20.i686 > gtk3-devel-3.10.5-1.fc20.i686 > nvidia version 304.108 I am using xserver 1:7.7+7 in my Debian testing with the internal jhbuild dependencies in GNOME 3.8.4 in Flashback mode and I still see tearing. Víctor was with me so he can confirm it. I think we should reopen this.
(In reply to comment #33) I am using xserver 1:7.7+7 in my Debian testing with the internal jhbuild dependencies in GNOME 3.8.4 in Flashback mode and I still see tearing. Víctor was with me so he can confirm it. > > I think we should reopen this. 1:7.7+7 is less than 1.14.4-5 right? Have you tried with a more recent version of Xorg?
(In reply to comment #34) > (In reply to comment #33) > I am using xserver 1:7.7+7 in my Debian testing with the internal jhbuild dependencies in GNOME 3.8.4 in Flashback mode and I still see tearing. Víctor was with me so he can confirm it. > > > > I think we should reopen this. > > 1:7.7+7 is less than 1.14.4-5 right? I am not sure, though it doesn't seem to. Any way to check it? > Have you tried with a more recent version of Xorg? Nope, it's the one that I have.
(In reply to comment #33) > (In reply to comment #32) > > Confirming what Zan Dobersek said in comment #20: > > > > Using Fedora20, with > > > > xorg-x11-server-Xorg-1.14.4-5.fc20.i686 > > gtk3-devel-3.10.5-1.fc20.i686 > > nvidia version 304.108 > > I am using xserver 1:7.7+7 in my Debian testing with the internal jhbuild dependencies in GNOME 3.8.4 in Flashback mode and I still see tearing. Víctor was with me so he can confirm it. > > I think we should reopen this. What graphics card? Driver?
(In reply to comment #36) > What graphics card? Driver? Intel Sandybridge with the i915.
I'll try and reproduce this. I think Victor and I were both using the Nvidia blob drivers when this got fixed on its own by using a combination of newer versions of GTK+ and the X server.