Issue 344141: HTML5 videos in full screen show visual tearing
Reported by
lukas.ri...@gmail.com,
Feb 15 2014
|
|||||||||||
Issue descriptionUserAgent: 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. Feb 17 2014,
Can you provide a screenshot or screenrecording of this behavior ? 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 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? 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 http://www.youtube.com/watch?v=22ftfoCSPQI to reproduce the rendering error. Mar 4 2014,Eric, I've got an Nvidia Quatro Mar 11 2014,
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? 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: https://www.dropbox.com/sh/xum70px3hq5xhia/Y_HdxyJog5 Firefox is free from tearing: https://www.dropbox.com/sh/sgypbisprjie1d3/hlmMbbVjTh 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. Nov 12 2014,Persistent tearing problem, neatly demonstrated in fullscreen on https://www.youtube.com/watch?v=d5agOAjjJsc#t=268 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. Nov 12 2014,
Jan 22 2015,tearing at 2560x1080. 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. 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? 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 http://album.alexflueras.ro/ 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. 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? CLUTTER_PAINT=disable-clipped-redraws:disable-culling CLUTTER_VBLANK=True 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. 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" EndSection ########## 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. 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 X.org); or - 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. 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. Apr 10 2015,#20 > (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. Apr 10 2015,#20 & #21 Nevermind, I see that it is basically already a band-aid for Firefox, VLC and others. 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.) https://bugs.launchpad.net/compiz/+bug/1442728 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. 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)". 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. 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? 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? https://code.google.com/p/chromium/codesearch#chromium/src/content/public/common/content_switches.cc&l=116 Dec 4 2015,
Dec 7 2015,I'm able to reproduce corruption / tearing on my workstation in windowed mode, using http://www.youtube.com/watch?v=22ftfoCSPQI. The corruption comes & goes, and is affected by the cursor position. The lower the cursor is vertically the more it occurs. Dec 7 2015,Attached video for #29. Dec 8 2015,
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+. 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 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. Refer to _NET_WM_BYPASS_COMPOSITOR https://specifications.freedesktop.org/wm-spec/latest/ar01s05.html#idm139870829920368 May 13 2016,After upgrading Ubuntu 16.04 from 15.10, tearing disappears. 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. May 10 2017,
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 ! 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. Sep 17 2017,Hello, Maybe a good way of dealing with this is to use the _NET_WM_BYPASS_COMPOSITOR standard property. http://cgit.freedesktop.org/xdg/xdg-specs/tree/wm-spec/wm-spec.xml#n1579 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. https://github.com/mpv-player/mpv/commit/ad3f75cc94adac9781fda93cc2a7c0c23ac0a606 https://github.com/mpv-player/mpv/commit/55846641eac86d55817be20eab00b8256a7e1c9a No bypass : _NET_WM_BYPASS_COMPOSITOR=0 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. 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) ! https://chromium-review.googlesource.com/c/chromium/src/+/532294 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 ! Dec 23 2017,Can this be fixed please ? Dec 26 2017,Experiencing this issue with Chromium 63.0.3239.108 with the VAAPI patches (from https://aur.archlinux.org/packages/chromium-vaapi-bin/) 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 Jan 6 2018,Come on Google can you fix this please ? A simple implementation of _NET_WM_BYPASS_COMPOSITOR will do the trick ! Jan 8 2018,
Jan 8 2018,
Setting _NET_WM_BYPASS_COMPOSITOR=2 seems ok to me. Jan 8 2018,Well indeed the other values doesn't really make sense in this case. Jan 8 2018, Project MemberThe following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4b59b70d81d879f9eb616aa4688ccc03944ae314 commit 4b59b70d81d879f9eb616aa4688ccc03944ae314 Author: Tom Anderson <thomasanderson@chromium.org> Date: Mon Jan 08 20:19:21 2018 X11: Always composite toplevel windows when possible BUG= 344141 R=piman,erg TBR=derat@chromium.org Change-Id: I3384b4bc207239fbcab3ddd25430c2ae76143e9c Reviewed-on: https://chromium-review.googlesource.com/854741 Reviewed-by: Thomas Anderson <thomasanderson@chromium.org> Reviewed-by: Elliot Glaysher <erg@chromium.org> Reviewed-by: Antoine Labour <piman@chromium.org> Commit-Queue: Thomas Anderson <thomasanderson@chromium.org> Cr-Commit-Position: refs/heads/master@{#527732} [modify] https://crrev.com/4b59b70d81d879f9eb616aa4688ccc03944ae314/ui/gfx/x/OWNERS [modify] https://crrev.com/4b59b70d81d879f9eb616aa4688ccc03944ae314/ui/gfx/x/x11_atom_cache.cc [modify] https://crrev.com/4b59b70d81d879f9eb616aa4688ccc03944ae314/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc Jan 8 2018,
The fix should appear in Chromium 65.0.3314.0 or later. Jan 9 2018,Thank you so much ! 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. lukas.ribisch@, Please find the attached screencast and GPU details for reference and confirm on the fix. Thanks..! Jan 9 2018, |
|||||||||||
►
Sign in to add a comment |
Comment 1 by lukas.ri...@gmail.com, Feb 15 2014