1678265 - A lot of time spent in SwapBuffer on https://eteam-eteam.4flow.cloud/#

Status: NEW

(Core :: Graphics: WebRender, enhancement)

Description

[Gabriele Svelto [:gsvelto]]

A friend of mine pointed me to this page:

https://eteam-eteam.4flow.cloud/#

It has a background that appears to be some kind animated SVG that changes every few seconds or so with some kind of fade-in/fade-out effect. Every time it does I can see a very large CPU spike in the main process. The animation appears to be running at 60FPS on my machine (Ryzen 3800X, Radeon RX 580 on Linux) but it consumes up to 60% CPU time to get there which seems a lot for such a simple effect.

Comment 1

[Mayank Bansal]

Profile with Wintel+ WR :https://share.firefox.dev/32ZBCGf

Comment 2

[Sotaro Ikeda [:sotaro OOO July/27 - July/31]]

:gsvelto, can you provide, about:support to this bug?

Comment 3

[Sotaro Ikeda [:sotaro OOO July/27 - July/31]]

When I tested with WebRender on Ubuntu18.04. Wait happened at GLContextGLX::SwapBuffers() on RenderThread. From it, the SVG animation seems like heavy weight for GPU with WebRender.
https://share.firefox.dev/33cTDkn

Comment 4

[Sotaro Ikeda [:sotaro OOO July/27 - July/31]]

:gw, can you comment to the bug?

Comment 5

[Gabriele Svelto [:gsvelto]]

Attachment: about:support

Comment 6

[Glenn Watson [:gw]]

If this is SVG, it might be updating a very large texture each frame it is animated?

nical or jrmuizel might know more about where to look for this, it seems likely that it would be related to blob code.

Comment 7

[Gabriele Svelto [:gsvelto]]

I gave a peek at the page sources and I think it's SVG but I'm not 100% positive.

Comment 8

[Jeff Muizelaar [:jrmuizel]]

The animated background is just 6 jpegs stacked on top with varying opacitys. WebRender should handle this fine. None of the profiles on the bug show anything particularly bad happening. For me cpu usage is around 30% which isn't great, but not terrible either.

Comment 9

[Nicolas Silva [:nical]]

I'm getting high renderer times (nothing crazy but fairly high still), with most of the time spent in SwapBuffer. There's also a noticeable portion of the time submitting draw calls (althought the amount of daw calls is farily low). GPU time is high as well (around 15ms) on the 4k intel (linux) which is probably why we end up waiting in SwapBuffer.

Comment 10

[Jim Mathies [:jimm]]

Can you investigate further?

Comment 11

[Nicolas Silva [:nical]]

I looked at what happens on the GPU: the large images are first blit from the texture cache to their own intermediate targets (likely because they are too large to both fit in one), and rendered into the screen with the opacity shader.
This is obviously super wasteful because we could draw the images directly off of the texture cache and save ourselves two intermediate targets each frame.
It would save a lot of GPU time but also avoid driver overhead associated with submitting work for the intermediate targets so some Renderer time as well.

What we want is some way to optimize away intermediate targets. This is the same as bug 1664478.

Comment 12

[Jim Mathies [:jimm]]

Hey Jim, could you take a look here, we're in need of a plan on how to improve things. Miko has been working on this as well.

Comment 13

[Jim Blandy :jimb]

Sure.