|Summary:||[GTK] Garbled rendering on Youtube while scrolling under X11.|
|Product:||WebKit||Reporter:||Ryan Farmer <rfarmer84>|
|Component:||WebKitGTK||Assignee:||Miguel Gomez <magomez>|
|Severity:||Normal||CC:||aboya, bugs-noreply, calvaris, cgarcia, commit-queue, magomez, mcatanzaro, webkit-bug-importer|
|Bug Depends on:|
Description Ryan Farmer 2018-12-21 08:54:29 PST
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 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.