Closed Bug 1134077 Opened 9 years ago Closed 6 years ago

HTML5 video tearing in full-screen mode on mutter (GNOME) due to vsync problem and compositor bypass

Categories

(Core :: Graphics, defect, P3)

Product:
Core
Component:
Graphics
Version:
40 Branch
Platform:
x86_64
Linux
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla60
Tracking Flags:
Tracking Status
firefox60 --- fixed

People

(Reporter: hancockrwd, Assigned: decltype)

References

Details

(Whiteboard: [gfx-noted])

Attachments

(1 file)

Bug 1134077 - X11: Set EWMH property to keep top-level nsWindows composited.
59 bytes, text/x-review-board-request
karlt
: review+
Details 
User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20150209173116

Steps to reproduce:

1. Ensure HTML5 mode is enabled on YouTube: https://www.youtube.com/html5
2. Play this video: https://www.youtube.com/watch?v=5xkNy9gfKOg
3. Switch to full-screen mode



Actual results:

Video tearing occurs when in full-screen mode on Fedora 21 - very visible as flickering in the vertical lines in this video. For the first few seconds of full-screen playback, it's basically fine. Then a few seconds after the seek bar and title bar disappear, suddenly it starts tearing. It's like there's a transition between two modes happening and the second mode is the one that has problems. Though, other times you can go to full screen and it shows tearing immediately.


Expected results:

Video plays without tearing. Other playback applications such as totem and VLC don't have this issue.
If it matters, this is on a machine with Intel Haswell integrated graphics:

00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
Does it work in the safemode ?
https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

The safemode disables the hardware graphic acceleration and all addons.
Flags: needinfo?(hancockrwd)
Component: Untriaged → Video/Audio
Product: Firefox → Core
The problem seems to still occur in safe mode.
Flags: needinfo?(hancockrwd)
After looking into this a bit more, it sounds like mutter (the GNOME3 compositor) has a heuristic that it uses to detect when it should unredirect the window. From https://github.com/ValveSoftware/steam-for-linux/issues/2163:

"GNOME 3 automatically unredirects some full-screen windows. Games (or SDL2) don't set the recently added _NET_WM_BYPASS_COMPOSITOR hint, so we fall back to heuristics: a non-ARGB32 full-screen / monitor-sized window that does 100 full-screen redraws in a row. If that happens, then the window should be unredirected."

When you open a full-screen video for the first time after opening the browser, after a few seconds (probably when 100 frames have been played), suddenly the video starts tearing. If you hit the Windows key to open the overview, which zooms down the video into a frame (presumably forcing it to be redirected again), the tearing stops. When you hit the key again to go back to full screen, it starts tearing again immediately.

Sure enough, if you disable unredirection as described here:

https://bugzilla.gnome.org/show_bug.cgi?id=741376#c15

the tearing goes away.

From what I'm reading, it sounds like the application ends up being responsible for handling vsync to avoid tearing when it's not redirected through the compositor. (I saw a bunch of reports of tearing on Ubuntu with Compiz when the "unredirect full screen" option was turned on.) If that's true and Firefox isn't doing this, then I'm assuming either that needs to be fixed or unredirection should be disabled for it.
Component: Video/Audio → Widget: Gtk
Summary: HTML5 video tearing in full-screen mode on Fedora → HTML5 video tearing in full-screen mode on Fedora maybe due to vsync problem with compositing
This bug doesn't affect Fedora only, same problem on Arch with nvidia drivers.

Meta.disable_unredirect_for_screen(global.screen)

fixes the problem.
This is still occurring in Firefox 40 on Fedora. Unfortunately the OMTC changes in this version don't resolve this issue, and also seem to cause YouTube videos to freeze up shortly after starting playback, so I had to layers.offmainthreadcomposition.enabled to false.
Version: 35 Branch → 40 Branch
I have this problem too.

My setup:
- openSUSE 13.2 (x86_64)
- Mozilla Firefox 41.0
- Youtube in HTML 5 mode
- NVidia driver 352.41
I have got the same problem on FreeBSD:
- FreeBSD 10.2
- xorg-7.7_2
- xf86-video-ati-7.5.0_2 (open source drivers for radeon)
- mate desktop 1.10
- firefox 40.0.3

In chromium and other video applications such as vlc or smplayer the problem with tearing does not exist.

My graphics card is Radeon HD 6450 (Caicos).
I can confirm this for Windows as well: Firefox 41.0.2, Windows 7 Pro x64, Nvidia display drivers 347.52.

But not only HTML5 video shows tearing - the same is true for WebGL using RequestAnimationFrame (see https://arnowelzel.de/wp/en/projects/example-for-webgl as an example).

There is no change when I configure the display drivers to force VSync.

The following values are also set to true (the default value):

gfx.vsync.compositor
gfx.vsync.hw-vsync.enabled
gfx.vsync.refreshdriver
Did you tried this to enable omtc :

layers.acceleration.force-enabled true
layers.offmainthreadcomposition.enabled true

No tearing for me on Fedora 22 with Nouveau divers with html5 videos. But I have some tearing with flash videos like I said here https://bugzilla.mozilla.org/show_bug.cgi?id=1226032
layers.offmainthreadcomposition.enabled already defaulted to true for me. Setting layers.acceleration.force-enabled did not help.
Are you still on Fedora 21 ?
No, Fedora 23 now, firefox-42.0-2.fc23.x86_64.
JFTR: The Windows-Version (Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0) has the same effect - layers.acceleration.force-enabled does not change anything and when setting layers.acceleration.force-enabled to true you can see how the framerate jumps around between 58 and 61, causing the tearing in videos and WebGL animations which use RequestAnimationFrame.
Hmm - one can not edit a comment here? Anway - when I wrote layers.acceleration.force-enabled I meant layers.acceleration.draw-fps.
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:51.0) Gecko/20100101 Firefox/51.0

I can confirm that I have the same effect on GTX 960M. An additional observation is that, this problem gets more visible according to size of content that changes. For the instance while I have a window of 50% of my screen, then this problem never happens. 

Such problem doesn't exist on Edge. Chrome hasn't been tested.
Component: Widget: Gtk → Graphics
I also have lot of tearing on HTML5 videos, in both normal and fullscreen mode in debian and FF 52,but nothing to do with firefox, I solved it enabling flipping on nvidia-configs and disabling composition, or using compton as composite manager, and run it with compton --backend glx --vsync opengl
Priority: -- → P3
Whiteboard: [gfx-noted]
I have tearing in windowed mode only - fullscreen is OK
Tearing eliminated with setting layers.acceleration.force-enabled preference to True in about:config page.
https://www.vsynctester.com/ test sill suffer
I have the same problem, fullscreen tearing. why is this bug still not confirmed?
With full-screen Firefox on Linux and an Intel GPU, I had no tearing when using KDE, but now with Gnome I do have tearing. I can see this both in videos and when scrolling in full-screen.

My theory is that Gnome unredirects the window in full-screen, and then Firefox fails to do proper v-sync.  KDE, on the other hand, does not do this heuristic-based unredirection, and hence Firefox' broken v-sync does not matter.

This is with Firefox 57 beta.
https://bugzilla.mozilla.org/show_bug.cgi?id=1412629

I have the same problem, only in Firefox. In Google Chrome no screen tearing.

Screen tearing in Firefox! (Scrolling, Watch Video...)
Problem not solved. Please, developers, fix it!


I am using Mozilla Firefox Latest Version.

AMD 5000+ CPU
GeForce 9500 GPU
4GB RAM
Win7 x64
FLATRON W1934S (59.9HZ ? or 60HZ i don't know)


PROBLEM NOT IN NVIDIA DRIVERS! SAME PROBLEMS WITH INTEL GRAPHICS.
Flags: needinfo?(milan)
Flags: needinfo?(milan)
Robert Hancock is correct, the tearing is due to some compositors unredirecting full-screen windows based on heuristics to reduce output latency. Since we don't ensure framebuffer updates happen during the vblank interval, this leads to the observed tearing. The easiest fix would be to set _NET_WM_BYPASS_COMPOSITOR to 2 ("don't unredirect") on all full-screen windows.

Note that Wayland users (default in Fedora) are not (yet) affected by tearing, as Mutter does not support unredirection when used as a wayland compositor: https://github.com/GNOME/mutter/blob/27b949d6babb14c87a760ceb4e21b80f0855fa7a/src/compositor/meta-surface-actor-wayland.c#L69,L87
Assignee: nobody → mozilla
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
_NET_WM_BYPASS_COMPOSITOR is requested here :

https://bugzilla.mozilla.org/show_bug.cgi?id=1226032
> Since we don't ensure framebuffer updates happen during the vblank interval, this leads to the observed tearing. The easiest fix would be to set _NET_WM_BYPASS_COMPOSITOR to 2 ("don't unredirect") on all full-screen windows.

That would however come with a performance impact, in particular on 4k screens, see e.g. https://bugzilla.gnome.org/show_bug.cgi?id=789929

Ideally, Firefox would do rendering in a way that it's v-synced so that the compositor just has to swap the buffers and not do any copies for tear-free rendering.
(In reply to Ralf Jung from comment #29)
> Ideally, Firefox would do rendering in a way that it's v-synced

Yes, but it doesn't at this stage and so bypassing the compositor is not
appropriate.

> That would however come with a performance impact, in particular on 4k
> screens, see e.g. https://bugzilla.gnome.org/show_bug.cgi?id=789929

I can't explain why you see such a difference.  Yes, it makes some difference
to performance, but compositing is an operation that the GPU should be able to
perform quickly and easily.

I don't see such problems with kwin and concurrently playing composited
fullscreen videos on each of two 4k monitors attached to
00:02.0 VGA compatible controller Intel Corporation HD Graphics 530 (rev 06).
One of the windows has an unfocused fade effect.

Perhaps there is a slow effect that mutter is applying, or maybe a problem with
XWayland, but this is just speculation.
Summary: HTML5 video tearing in full-screen mode on Fedora maybe due to vsync problem with compositing → HTML5 video tearing in full-screen mode on mutter (GNOME) due to vsync problem and compositor bypass
Comment on attachment 8947946 [details]
Bug 1134077 - X11: Set EWMH property to keep top-level nsWindows composited.

https://reviewboard.mozilla.org/r/217614/#review223520

_NET_WM_BYPASS_COMPOSITOR 2 is appropriate, thanks.
Are you able to make these small changes, please?

::: toolkit/library/moz.build:272
(Diff revision 1)
>      OS_LIBS += CONFIG['MOZ_DBUS_GLIB_LIBS']
>  
>  if 'gtk' in CONFIG['MOZ_WIDGET_TOOLKIT']:
>      if CONFIG['MOZ_WIDGET_TOOLKIT'] == 'gtk3':
>          OS_LIBS += [l for l in CONFIG['TK_LIBS']
> -            if l not in ('-lgtk-3', '-lgdk-3')]
> +            if l not in ('-lgtk-3')]

Even though there is no documentation here, the existing logic is necessary for loading Flash with GTK2 from the same object file, so leave this as is.

See widget/gtk/mozgtk/mozgtk.c to add support for new gdk symbols.

::: widget/gtk/nsWindow.cpp:3890
(Diff revision 1)
> +#ifdef MOZ_X11
> +    // Set window manager hint to keep fullscreen windows composited
> +    if (mShell && mIsTopLevel && mIsX11Display) {
> +        gulong value = 2; // Opt out of unredirection
> +        GdkAtom cardinal_atom = gdk_x11_xatom_to_atom(XA_CARDINAL);
> +        gdk_property_change(gtk_widget_get_window(mShell),
> +                            gdk_atom_intern("_NET_WM_BYPASS_COMPOSITOR", FALSE),
> +                            cardinal_atom,
> +                            32, // format
> +                            GDK_PROP_MODE_REPLACE,
> +                            (guchar*)&value,
> +                            1);
> +    }
> +#endif
> +

Can you move this to the end of the switch block that sets mIsTopLevel, please?

That saves having to check mShell and mIsTopLevel, and avoids
splitting the code that connects all the event handlers.

::: widget/gtk/nsWindow.cpp:3891
(Diff revision 1)
>                                 "notify::gtk-font-name",
>                                 G_CALLBACK(theme_changed_cb), this);
>      }
>  
> +#ifdef MOZ_X11
> +    // Set window manager hint to keep fullscreen windows composited

Please indicate here why this is done.
Something like "because Gecko does not align its framebuffer updates with vblank".
Attachment #8947946 - Flags: review?(karlt) → review-
Attachment #8947946 - Flags: feedback+
Comment on attachment 8947946 [details]
Bug 1134077 - X11: Set EWMH property to keep top-level nsWindows composited.

https://reviewboard.mozilla.org/r/217614/#review223520

> Even though there is no documentation here, the existing logic is necessary for loading Flash with GTK2 from the same object file, so leave this as is.
> 
> See widget/gtk/mozgtk/mozgtk.c to add support for new gdk symbols.

Oh, so that's why those libs were excluded.

I added gdk_property_change in widget/gtk/mozgtk/mozgtk.c.

> Can you move this to the end of the switch block that sets mIsTopLevel, please?
> 
> That saves having to check mShell and mIsTopLevel, and avoids
> splitting the code that connects all the event handlers.

Done.

> Please indicate here why this is done.
> Something like "because Gecko does not align its framebuffer updates with vblank".

Done.
Comment on attachment 8947946 [details]
Bug 1134077 - X11: Set EWMH property to keep top-level nsWindows composited.

https://reviewboard.mozilla.org/r/217614/#review223746

Thank you!
Attachment #8947946 - Flags: review?(karlt) → review+
Keywords: checkin-needed
Pushed by csabou@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/0561afeb9ca1
X11: Set EWMH property to keep top-level nsWindows composited. r=karlt
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/0561afeb9ca1
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
status-firefox60: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla60
Depends on: 1464679
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: