stripe.com has huge GPU times in Gecko

[jrmuizel]

I was seeing 222ms times, so there's probably something very wrong happening.

[jrmuizel]

Bugzilla issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1414357

[jrmuizel]

Here's a yaml file that reproduces the problem: http://jrmuizel.github.io/webrender/stripe.zip

[glennw]

Hopefully #1961 and/or #1984 will fix this, but I'll profile after they are sorted to confirm.

[glennw]

I'm seeing ~40ms on my HD4600. There doesn't seem to be too much time spent in shadows / blurs, but there is a huge amount of time spent generating clips (and clearing clip targets). Most of these appear redundant. There's also a lot of time spent in the slow transform shaders, which will be resolved once we land the brush changes to draw inner segments as opaque.

[jrmuizel]

Should we expect this to be fixed yet?

[nical]

Caching what we render into intermediate targets would help a lot here.

[glennw]

No, I wouldn't expect this to be fixed yet. We need to leverage and extend the segment support to optimize the clips and inset box shadows.

I've been thinking about caching the results of intermediate surfaces a bit. I think it should be relatively straightforward, by building on top of the Picture tree. The basic idea would be to detect when the contents of a Picture are the same, and redirect the rendering location from an intermediate surface to the texture cache instead. I'll try and write up a more detailed plan for this over the next week or two. Having said that, once the segment optimizations apply to more types of clips and box-shadows, it probably won't be necessary in this case (but still good for power usage anyway).

[glennw]

This is a lot better than it was - I'm seeing ~10-12ms on my HD4600. I'll leave it open as it can still be improved a lot though. We are spending a lot of time on redundant clip masks, and blurs than can be cached.

[dralley]

The bugzilla is marked "resolved fixed", can this be closed?

[kvark]

Thanks for triaging!