WebRender has a bad time with https://jrmuizel.github.io/perf-tests/moving-balls.html

[jrmuizel]

Profiling servo running this test case shows about 50% of the time in WebRender. The rendering is also incorrect (the solid colors leak out of the borders)

[glennw]

Wow, of the 33ms spent in the backend thread, 20ms of that is DL deserialization and processing :(

[kvark]

Sounds like @gankro should be accused involved

[jrmuizel]

rust-lang/rust#31681 should help here.

[glennw]

This looks correct visually now, but the CPU performance is still a problem. Needs more investigation.

[kvark]

I took some measurements. CPU backend time is 50ms. Although, 2/3 of that appears to be spent in just waiting for messages (pthread_cond_wait). The rest is mostly spent on scene building.

On the CPU compositor time, GPU cache is only taking 3%, less then the Intel driver spent querying it's own extensions on each draw call (d'oh).

Is it possible for Gecko to use the dynamic transform properties here, avoiding the frame building cost?

[kvark]

I looked at the GPU profile, and there is more than expected number of draw calls there. We switch between solid/corder/edge ~50 times.

One thing that could help is a better batching policy, one that is based on the approximated screen coverage instead of a fixed number of past batches to look at.

Another thing I noticed is that the edge draw calls contributed nothing, because the edges have zero heights. I've implemented the extra checks in both the frame builder and the renderer to avoid issuing those calls in #2630, which brings down the total draw call count from 170+ to 120.

[jrmuizel]

Here's my profile:
https://perfht.ml/2H2fPnn

The biggest problem is style, but the render backend is spending 74ms moving memory around.

[kvark]

As @jrmuizel mentioned, we are also spending 18% of time allocating the space in our texture atlas. This time may be saved once we start re-using the clip masks between items (as mentioned by @glennw in #2626 (comment)), since a lot of the 2294 clips look similar:

[gw3583]

Although this does still run very slowly in WR, it's significantly faster than vanilla Gecko (on my machine, at least). The rendering does look correct now. We can leave this open but it's low priority - the test case runs quite badly on all browsers I tested.

[gw3583]

This runs at a reasonable kind of frame rate given the content for me now.