Bug 192982 – [GTK] Garbled rendering on Youtube while scrolling under X11.

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Ryan Farmer]

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?)

[Ryan Farmer]

Created attachment 357948 [details]
Red garbage in the webview while playing a video and scrolling.

[Michael Catanzaro]

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.

[Ryan Farmer]

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%.

[Ryan Farmer]

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.

[Michael Catanzaro]

Yep, I'll add it to the list.

[Ryan Farmer]

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.

[Michael Catanzaro]

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.)

[Miguel Gomez]

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.

[Miguel Gomez]

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?

[Alicia Boya García]

(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.

[Xabier Rodríguez Calvar]

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)

[Miguel Gomez]

(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.

[Miguel Gomez]

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.

[Miguel Gomez]

Created attachment 358889 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 358889 [details]
Patch

Clearing flags on attachment: 358889

Committed r239869: <https://trac.webkit.org/changeset/239869>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Michael Catanzaro]

*** Bug 193001 has been marked as a duplicate of this bug. ***