Bug 192982 - [GTK] Garbled rendering on Youtube while scrolling under X11.
Summary: [GTK] Garbled rendering on Youtube while scrolling under X11.
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: Other
Hardware: PC Linux
: P2 Normal
Assignee: Miguel Gomez
URL:
Keywords:
: 193001 (view as bug list)
Depends on:
Blocks: 192523
  Show dependency treegraph
 
Reported: 2018-12-21 08:54 PST by Ryan Farmer
Modified: 2019-02-05 08:03 PST (History)
8 users (show)

See Also:


Attachments
Blue garbage in the Webview while scrolling Youtube's main page. (224.71 KB, image/png)
2018-12-21 08:54 PST, Ryan Farmer
no flags Details
Red garbage in the webview while playing a video and scrolling. (1.87 MB, image/png)
2018-12-21 08:55 PST, Ryan Farmer
no flags Details
Patch (5.88 KB, patch)
2019-01-11 04:03 PST, Miguel Gomez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ryan Farmer 2018-12-21 08:54:29 PST
Created attachment 357947 [details]
Blue garbage in the Webview while scrolling Youtube's main page.

On Fedora 29 with Epiphany 3.30.2 and WebkitGTK 2.22.5 and on the GNOME on Xorg (X11) session, I get garbled rendering while scrolling on youtube.com.

I'm using Intel Iris 540 graphics (Skylake mobile).

I've attached some screenshots. 

This behavior never occurs when using GNOME on Wayland. (The Fedora default, but many users, even entire distributions, switch it back to GNOME on Xorg.)

The webview flashes blue intermittently while scrolling Youtube's main page and either red or orange (everywhere outside the video) while playing a video and scrolling.

Additionally, while playing a video, the page freezes up while the red or orange flickering is going on. Sometimes for several seconds.

(I don't know if this would have anything to do with the problem, but a former Microsoft Edge developer complained that Google is playing dirty tricks to make Youtube not work *quite* right if you aren't using Chrome/Chromium. He specifically mentioned that they load an empty div over each video to sabotage Edge's hardware accelerated video playback and that they feed their own web browser a special version of the whole site that only runs in Chrome, and hand other browsers a "Javascript heavy" version that runs "five times slower". Don't you love Google?)
Comment 1 Ryan Farmer 2018-12-21 08:55:58 PST
Created attachment 357948 [details]
Red garbage in the webview while playing a video and scrolling.
Comment 2 Michael Catanzaro 2018-12-21 09:41:13 PST
Hm that's not good... please do try running with WEBKIT_DISABLE_COMPOSITING_MODE=1 to possibly rule out hardware acceleration as a potential problem.
Comment 3 Ryan Farmer 2018-12-21 10:20:32 PST
Okay(In reply to Michael Catanzaro from comment #2)
> Hm that's not good... please do try running with
> WEBKIT_DISABLE_COMPOSITING_MODE=1 to possibly rule out hardware acceleration
> as a potential problem.

Yes, that stopped the corruption and the scrolling is much smoother and doesn't rev up my laptop's fan.

I suppose this bug should probably be added to the list in issue 595 "Accelerated compositing mode is broken" on Epiphany's Gitlab.

https://gitlab.gnome.org/GNOME/epiphany/issues/595

On a semi-related note, this also improves performance on (at least) Facebook and Riot.im on my laptop. No more clunky scrolling with the fan running at 100%.
Comment 4 Ryan Farmer 2018-12-21 10:28:01 PST
FWIW, browsers like Firefox and Chromium have either blacklisted OpenGL compositing on GNU/Linux and/or have applied a ton of clumsy driver workarounds.

I'm afraid to say that even with the latest Intel open source stack (Linux kernel, Mesa, Xorg), Chromium's list of broken driver workarounds hasn't gotten a lot smaller, and you still have to enable OpenGL compositing through Flags.
Comment 5 Michael Catanzaro 2018-12-21 11:28:28 PST
Yep, I'll add it to the list.
Comment 6 Ryan Farmer 2018-12-21 14:09:39 PST
I ended up liking the experience better with hardware compositing off because the  performance isn't great with it on and it revs up my laptop fan on certain websites. Should the performance issues be another bug? Does it only affect Intel hardware or something?

In any event, I disabled hardware compositing permanently on my system.
Comment 7 Michael Catanzaro 2018-12-22 12:38:18 PST
Yes, I would file another bug for the performance issues on your hardware. Accelerated compositing  (GPU rendering) is supposed to be faster than software rendering, not slower.

(I highly doubt all Intel hardware is affected, since almost everyone has Intel graphics.)
Comment 8 Miguel Gomez 2019-01-02 04:59:12 PST
I can reproduce this with ToT on my system with an intel video card as well. The CPU consumption is huge just playing the video (should be minimum as it should be hw accelerated). When scrolling, when reaching the point when the page loads new content, I can see that all the page (or the bg) turns red or yellow.
Comment 9 Miguel Gomez 2019-01-02 05:20:29 PST
The excessive CPU usage is reproducible playing a normal video, both with and without AC. I've tested that it happens even if we are not painting the video frames at all, so I must be something inside gstreamer.

I see that while playing a youtube video with 1080p it's using all my system processors (8) at 20% each.

BTW, I'm using Fedora 29 as well. Maybe it's a decoding issue? Charlie, Calvaris, Alicia, any thoughts?
Comment 10 Alicia Boya García 2019-01-10 12:56:25 PST
(In reply to Miguel Gomez from comment #9)
> The excessive CPU usage is reproducible playing a normal video, both with
> and without AC. I've tested that it happens even if we are not painting the
> video frames at all, so I must be something inside gstreamer.
> 
> I see that while playing a youtube video with 1080p it's using all my system
> processors (8) at 20% each.
> 
> BTW, I'm using Fedora 29 as well. Maybe it's a decoding issue? Charlie,
> Calvaris, Alicia, any thoughts?

Software decoding video (especially VP9) is a parallelizable CPU intensive task, so there being a noticeable CPU usage is nothing unusual by itself.

Of course, the complex graphic pipeline WebKit introduces to render the video inside a webpage can also have an impact.
Comment 11 Xabier Rodríguez Calvar 2019-01-10 22:45:44 PST
I guess it would be interesting to see the pipeline to check if there's hw acceleration or not. Maybe running with GST_DEBUG_DUMP_DOT_DIR=/tmp env var and posting here the png file of the PAUSED->PLAYING transition.

(PNGs can be obtained from the generated .dot files by running dot -Tpng -oimage.png graph_lowlevel.dot)
Comment 12 Miguel Gomez 2019-01-11 01:52:28 PST
(In reply to Alicia Boya García from comment #10)
> (In reply to Miguel Gomez from comment #9)
> > The excessive CPU usage is reproducible playing a normal video, both with
> > and without AC. I've tested that it happens even if we are not painting the
> > video frames at all, so I must be something inside gstreamer.
> > 
> > I see that while playing a youtube video with 1080p it's using all my system
> > processors (8) at 20% each.
> > 
> > BTW, I'm using Fedora 29 as well. Maybe it's a decoding issue? Charlie,
> > Calvaris, Alicia, any thoughts?
> 
> Software decoding video (especially VP9) is a parallelizable CPU intensive
> task, so there being a noticeable CPU usage is nothing unusual by itself.
> 
> Of course, the complex graphic pipeline WebKit introduces to render the
> video inside a webpage can also have an impact.

Ok, I wasn't expecting the decoding to happen on the CPU, that explains a lot. I guess I'm too used to embedded devices where there's a hw decoder available :). No issue with the CPU usage then.
Comment 13 Miguel Gomez 2019-01-11 01:55:57 PST
I found the reason of the strange colors showing up on the page. The problem is that we are creating a glcontext for the window whose default framebuffer doesn't have a stencil buffer (neither a depth one). Due to this, when we do stencil clipping on the default framebuffer it doesn't work properly, leaking to the page the last color we painted with.

I'm cooking a patch that creates a context using a GLXFBConfig that is compatible with the one used by the window but having a depth and stencil buffer.
Comment 14 Miguel Gomez 2019-01-11 04:03:06 PST
Created attachment 358889 [details]
Patch
Comment 15 WebKit Commit Bot 2019-01-11 13:01:53 PST
Comment on attachment 358889 [details]
Patch

Clearing flags on attachment: 358889

Committed r239869: <https://trac.webkit.org/changeset/239869>
Comment 16 WebKit Commit Bot 2019-01-11 13:01:55 PST
All reviewed patches have been landed.  Closing bug.
Comment 17 Michael Catanzaro 2019-01-28 07:39:34 PST
*** Bug 193001 has been marked as a duplicate of this bug. ***