New issue
Advanced search Search tips
Starred by 30 users

Issue metadata

Status: Fixed
Closed: Jan 2018
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug

Sign in to add a comment

Issue 344141: HTML5 videos in full screen show visual tearing

Reported by, Feb 15 2014

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. Open a Youtube video using the HTML5 player
2. Switch to fullscreen playback
3. See horizontal lines (vsync artefacts?) in scenes with high movement

What is the expected behavior?

What went wrong?
Using a stock Ubuntu 13.10 environment (Unity) with an Intel HD 4000 GPU (no special settings) shows visible screen tearing only for full screen HTML5 videos. Regular (in-tab) HTML5 videos work; Flash is also not a problem (even in full screen mode).

Firefox does not have this problem on the same machine.

Did this work before? N/A 

Is it a problem with Flash or HTML5? HTML5

Does this work in other browsers? Yes 

Chrome version: 32.0.1700.107  Channel: stable
OS Version: Kernel 3.11/Ubuntu 13.10
Flash Version: Shockwave Flash 12.0 r0

When returning from fullscreen, the Unity desktop shows some graphical glitches until the next full repaint: the video content and/or controls are displayed instead of the menu bar and the Unity bar. This also does not happen for Flash videos in Chrome and for any videos in Firefox. Chrome's method of full screen painting seems to be broken or is triggering some bug in Unity.

Comment 1 by, Feb 15 2014

This seems to happen for all full screen content, not just HTML5 videos. Horizontal scrolling in full screen mode shows those artefacts as well (easily reproducible by visiting a very wide page like and scrolling in full screen mode). The desktop overwriting glitches happen as well.

Comment 2 by, Feb 17 2014

Labels: Needs-Feedback
Can you provide a screenshot or screenrecording of this behavior ?

Comment 3 by, Feb 19 2014

I could not repro this on Ubuntu 13.10 on Chrome stable. It might be worth checking this on an Intel GPU. In the mean time, lukas.ribisch, can you go to Chrome://flags and enable "override software rendering list" near the top, and let us know if this helps

Comment 4 by, Feb 26 2014

per #3: lukas.ribisch - can you please attempt a repro per ajnolley@ and let us know if this still repro's for you?

@ajnolley : what GPU did you have?

Comment 5 by, Feb 27 2014

I've tried it with Chrome 33 with and without the flag for overriding the software rendering list, here is what I've observed:

- The tearing problem now only seems to occur in some situations; mostly only after switching to the full-screen view. It goes away after a few seconds.
- The problem with broken desktop rendering when returning from fullscreen still occurs. While it occurs, there is also vsync tearing in the video inside the tab.
- I'm not able to capture the problem with a screenshot - just pressing the "print screen"-button immediately restores the correct desktop rendering.
- The software rendering list doesn't seem to make a difference (Which seems logical; even without the rendering list override, about:gpu shows that Chrome is already using my Intel GPU for "Video" (but not "Video Encode") and Compositing.

I've used to reproduce the rendering error.

Comment 6 by, Mar 4 2014

Eric, I've got an Nvidia Quatro

Comment 7 by, Mar 11 2014

Labels: -Pri-2 Pri-3
Status: Available
as do I, and I cannot repro this issue on 12.04 LTS w/nVidia Quadro 600 running driver vers. 319.32.  no tearing producing horizontal lines at all using the video above.  

When you drag a window around on the desktop, do you also notice tearing?

Comment 8 by, May 3 2014

I also have tearing problems in Chromium. All symptoms (including changing the flags) are the same as described by Lukas. I'm using Ubuntu 14.04, video card is Intel HD4600 (Haswell CPU). I made photos to compare the Chromium v.s. Firefox outputs:

Chromium, note that vertical bars are "torn" by horizontal lines:

Firefox is free from tearing:

Comment 9 by, Oct 21 2014

I'm having the same issue on all fullscreen flash and HTML5 videos in Chrome, across multiple sites.  The issue is not present when playing videos in non-fullscreen mode.

Ubuntu 14.04, AMD Radeon HD 6970, catalyst driver from Canonical repos, Intel Core i7 2700K processor.

Comment 10 by, Nov 12 2014

Persistent tearing problem, neatly demonstrated in fullscreen on

No tearing occurs without fullscreen.

1920x1200, nVidia GT 640 with driver version 331.38 from official repositories, on Ubuntu 14.04 LTS x64

The exact line where tearing occurs seems to change depending on the cursor position on the screen.

Might or might not be relevant: I run a dual-monitor setup.

Comment 11 by, Nov 12 2014

Labels: Cr-Internals-Compositing Cr-Internals-GPU

Comment 12 by, Jan 22 2015

tearing at 2560x1080.

Comment 13 by, Apr 4 2015

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/41.0.2272.76 Chrome/41.0.2272.76 Safari/537.36

Same problem: Full screen HTML5 videos tear on Ubuntu 14.04, 14.10 and 15.04 with Unity.

Windowed videos never tear. Neither does Firefox (either full screen or windowed) or video players like VLC.

Full screen Pepper Flash doesn't seem to tear either.

It happens at least on a variety of Intel graphics (I've tested Sandy Bridge, Ivy Bridge, Bay Trail and Haswell) and one NVIDIA card with the Nouveau driver. I don't have an AMD machine available to test though.

In all of these configurations, Chromium in full screen is the only thing that doesn't properly V-sync. All other things work as intended.

Comment 14 by, Apr 4 2015

#13 Do you see the same effect as I did, where the line at which the tearing occurs depends on the position of the cursor, but not the content?

Comment 15 by, Apr 4 2015

The cursor placement doesn't really seem to matter. I also see multiple tear lines; not just one.

I've done some more tests:

- Overriding the GPU whitelist makes no difference at all.

- Setting "Don't wait for video sync" and/or "Force full screen redraws on repaint" as Compiz workarounds make no difference.

- Setting TearFree for the Intel X driver or EXAVSync for the Nouveau X driver makes no difference.

- I've never noticed any kind of corruption or glitches on switching to/from full screen. It just tears, but that's all.

- Scrolling on after pressing F11 does *not* seem to tear on any of my machines. It only seem to be HTML5 videos (which do not tear in Firefox).

I guess I'll be testing other window managers next, but I also remember Chromium being the only thing that tears on an Xfce+Compton setup of a family member.

All in all, I really wonder what's the deal with Chromium's V-sync on Linux. It's the only application I can't get to work properly on any hardware; modern or old, whatever graphics card or DE used.

Comment 16 by, Apr 5 2015

Do you who have this issue get tearing also on local videos played in external media players?

Intel graphics users: have you tried adding following lines to /etc/environment?


Comment 17 by, Apr 5 2015

> Do you [...] get tearing also on local videos played in external media players?

No. Full-screen Chromium videos are the *only* things that ever tear on any of my systems. Using VLC, MPlayer, Firefox or whatever other application works without any issues.

> Intel graphics users: have you tried adding following lines to /etc/environment?

Yes. It changes nothing. Everything will V-sync *except* for full-screen videos in Chromium.

Also tested on AMD radeonsi now. Same issue as with i915 and nouveau.

Comment 18 by, Apr 6 2015

Ok, I've done some more tests.

- Pressing F11 to make Chromium full screen but keeping the video itself within a page, also causes it to tear. Pressing F11 again to return to a normal window makes the video V-sync again.

- I spoke too soon about Intel TearFree: it does work. (I will test other FOSS drivers later.)

For now, I've created /etc/X11/xorg.conf.d/20-intel.conf with the following contents:

Section "Device"
  Identifier "Intel Graphics"
  Driver "intel"
  Option "TearFree" "true"

Full screen videos no longer seem to tear in Chromium (either by pressing F11 or having the actual video go full screen).

However, this does make me wonder why Chromium is the *only* application on my computer that needs TearFree to be enabled explicitly. Does it bypass the OpenGL compositor somehow while all other video players (and Firefox) don't?

I'm also not yet sure about stability or performance impacts of Intel TearFree. I doubt it's disabled by default for no reason.

Comment 19 by, Apr 7 2015

I'm at a client's home now who has an AMD Kabini APU using the radeonsi driver on Ubuntu 14.04 with Unity.

The situation here is the same as I described in post #13: everything works perfectly except for full-screen Chromium videos.

Apparently the only way to get Chromium to work is by enforcing a driver-level V-sync option, as I successfully did with TearFree on Intel devices.

The radeon driver features the EXAVsync parameter which probably does the same. However, modern AMD GPU's no longer support EXA: they all use Glamor. And Glamor has no V-sync options (yet). So we'll have to rely on the OpenGL compositor to V-sync. (Which Compiz does very well without any tweaks.)

My guess is that Chromium (Aura?) bypasses the compositor completely in full-screen mode, dropping all V-sync capabilities. The only way to alleviate that is by having the driver V-sync (unnecessarily for *all* other applications than Chromium). And that's something that not every driver can do. In fact, I've only seen i915 and NVIDIA's unauditable binary blob do it properly.

So if my assumption is right, Chromium should either:

- Stop bypassing the compositor in full-screen mode (at least on;
- Get Aura to V-sync properly (like Compiz, GNOME Shell, KWin, Compton, et cetera).

In any case, this should be fixed, because I've had lots of clients going back to Firefox now its Media Source capabilities are improving.

Comment 20 by, Apr 10 2015

I finally found a fix that works on all drivers.

My suspicion was right: Chromium bypasses the compositor which causes it to tear.
Apparently Unity has workarounds for this, which aren't enabled by default for Chromium. (I'll file a Compiz bug for that.)

Anyway, you'll need to install CompizConfig Settings Manager (sudo apt-get install compizconfig-settings-manager) and navigate to the "Composite" tab.

There, you'll see the option "Unredirect Match" containing the following line:

(any) & !(class=Totem) & !(class=MPlayer) & !(class=Vlc) & !(class=Plugin-container) & !(class=Firefox)

Simply change that into:

(any) & !(class=Totem) & !(class=MPlayer) & !(class=Vlc) & !(class=Plugin-container) & !(class=Firefox) & !(class=Chromium)

This will keep a full-screen Chromium window managed by Compiz and thus V-synced.

Comment 21 by, Apr 10 2015


> (I'll file a Compiz bug for that.)

What if it causes other subtle issues? This bypass is probably in place for a reason, need to hear from a Chromium dev.

Comment 22 by, Apr 10 2015

#20 & #21

Nevermind, I see that it is basically already a band-aid for Firefox, VLC and others.

Comment 23 by, Apr 10 2015

> What if it causes other subtle issues?

I'm quite sure it reduces performance, but I'd still prefer that to tearing.
Like you said, it's already a patch for Firefox and popular video players.

> This bypass is probably in place for a reason.

No, it's *not* in place by default. :)

> Need to hear from a Chromium dev.

I don't think any Chromium dev is to "blame" for this. It's a Unity/Compiz default setting.

> (I'll file a Compiz bug for that.)

If they have a reason for not including Chromium, I guess we'll find out.
For now, I've been testing it non-stop for hours on i915, radeonsi, and nouveau without any problems.

Comment 24 by, Apr 10 2015

For the record, "Chromium" class will not work for Chrome browser.

Corresponding classes are "Google-chrome-stable", and presumably "Google-chrome-beta", "Google-chrome-unstable".

So for Chrome, the needed filter is "& !(class=^Google-chrome)".

Comment 25 by, Apr 14 2015

Both "Tearfree" and the Compiz configuration fix the issue completely for me.

Thank you very much for your efforts; I would never have guessed that this might actually be a problem with my OS, since all the other applications I've compared with are on the exception list by default.

Comment 26 by, Jun 25 2015

So, that's all? o_O How about people who use xcompmgr, compton or no composite manager at all? "Just use Compiz" is not answer! Where settings in Chrome to FORCE vsync on?

Comment 27 by, Jun 25 2015

It's not a great fix, but have you tried "--disable-gpu-compositing" or "--disable-gpu" on the command line to see if the issue is resolved?

Comment 28 by, Dec 4 2015

Labels: -Pri-3 Pri-2 Hotlist-Polish

Comment 29 by, Dec 7 2015

I'm able to reproduce corruption / tearing on my workstation in windowed mode, using  The corruption comes & goes, and is affected by the cursor position.  The lower the cursor is vertically the more it occurs.

Comment 30 by, Dec 7 2015

Attached video for #29.
2.7 MB Download

Comment 31 by, Dec 8 2015

Status: ExternalDependency
The issue in #29 / #30 is with Metacity.  All of the UI tears with Metacity.  Switching to Compiz solves that form me on Chrome 47, even without the workaround in #20.

Re #26: Chrome currently has VSync configured ON unless you disable it.  It's unfortunate that it is a complicated story, but your VSync support on Linux depends on your driver, window manager, and how you configure them.

For now I'm marking this as ExternalDependency.  Please re-open if you are having issues on Chrome 47+.

Comment 32 by, Mar 20 2016

#31 You said to re-open if on 47+. Still same issue. Haven't yet tried the work around #20 as stated above. 

Ubuntu 14.04 LTS - Chrome 49.0.2623.87 (Official Build) (64-bit)
- Intel HD Graphics 2000

Comment 33 by, May 13 2016

disable "Unredirect Fullscreen Windows" in "CompizConfig setting manager" fixes this issue.

Since Ubuntu 13.04, "Unredirect Fullscreen Windows" is enabled by default, which windows compositor doesn't composite fullscreen window. For some reason, when chromium displays fullscreen by itself, vsync is not respected.

Comment 34 by, May 13 2016

After upgrading Ubuntu 16.04 from 15.10, tearing disappears.

Comment 35 by, May 16 2016

We disable vsync in Chromium when a compositing window manager is on, because the compositing window manager is responsible for vsync, and also doing vsync in Chrome leads to poor performance.
Unfortunately, I don't think we get feedback about the window being unredirected (when that happens depends on the compositing manager), at which point we would need to turn vsync back on. We could tentatively turn on vsync on fullscreen windows, but I'm concerned about potential regressions on compositing managers that keep fullscreen windows redirected.

Comment 36 by, May 10 2017

Owner: ----

Comment 37 by, Sep 10 2017

I have tearing with Chrome 61 on Fedora 26 with intel drivers (sna, dri3 and tearfree). I don't have tearing with mpv or firefox (with layers.acceleration.force-enabled set to true).

Can this be fixed please ? Thanks !

Comment 38 by, Sep 17 2017

I have the same issue present with Chrome 61, Ubuntu 16.04 and Intel drivers. Non-fullscreen videos are played well, whereas fullscreen videos have tearing and FPS drop.

Comment 39 by, Sep 17 2017


Maybe a good way of dealing with this is to use the _NET_WM_BYPASS_COMPOSITOR standard property.

It allow an app to force the compositor to keep compositing enabled or not. A good way of implementing it is like MPV did with 4 use case that the user can choose.

Compositing always enabled : _NET_WM_BYPASS_COMPOSITOR=2
Compositing always disabled : _NET_WM_BYPASS_COMPOSITOR=1
Compositing disabled only in Fullscreen : _NET_WM_BYPASS_COMPOSITOR=1 if in Fullscreen

The default would be "Compositing always enabled : _NET_WM_BYPASS_COMPOSITOR=2" to always keep the compositing enabled and thus fix the tearing problem.

Comment 40 by, Oct 5 2017

Now that video hardware acceleration is close to land for Linux it's too bad there is tearing on the most used desktops environments (Gnome, Unity as they unredirect fullscreen windows) !

Comment 41 by, Oct 10 2017

By the way, Unity workaround this problem by not unredirecting chrome / chromium. With the Ubuntu switch to Gnome that won't be possible anymore as Mutter doesn't allow this. Please fix this problem !

Comment 42 by, Dec 23 2017

Can this be fixed please ?

Comment 43 by, Dec 26 2017

Experiencing this issue with Chromium 63.0.3239.108 with the VAAPI patches (from

Using GNOME on X11 with the modesetting Xorg driver

Disabling the bypassing of the compositor in fullscreen will fix this issue
Verified this by running mpv with --x11-bypass-compositor=never

Comment 44 by, Jan 6 2018

Come on Google can you fix this please ? A simple implementation of _NET_WM_BYPASS_COMPOSITOR will do the trick !

Comment 45 by, Jan 8 2018


Comment 46 by, Jan 8 2018

Status: Started (was: ExternalDependency)
Setting _NET_WM_BYPASS_COMPOSITOR=2 seems ok to me.

Comment 47 by, Jan 8 2018

Well indeed the other values doesn't really make sense in this case.

Comment 48 by, Jan 8 2018

Project Member
The following revision refers to this bug:

commit 4b59b70d81d879f9eb616aa4688ccc03944ae314
Author: Tom Anderson <>
Date: Mon Jan 08 20:19:21 2018

X11: Always composite toplevel windows when possible

BUG= 344141 

Change-Id: I3384b4bc207239fbcab3ddd25430c2ae76143e9c
Reviewed-by: Thomas Anderson <>
Reviewed-by: Elliot Glaysher <>
Reviewed-by: Antoine Labour <>
Commit-Queue: Thomas Anderson <>
Cr-Commit-Position: refs/heads/master@{#527732}

Comment 49 by, Jan 8 2018

Status: Fixed (was: Started)
The fix should appear in Chromium 65.0.3314.0 or later.

Comment 50 by, Jan 9 2018

Thank you so much !

Comment 51 by, Jan 9 2018

Tested this issue on Linux-Ubuntu-14.04 using chrome latest Canary-65.0.3316.0 as per C#0.
No horizontal lines observed while playing youtube video using html5 player in full screen mode and normal mode.

Please find the attached screencast  and GPU details for reference and confirm on the fix.
12.3 KB View Download

Comment 52 by, Jan 9 2018

27.2 MB Download

Sign in to add a comment