Webrender: MotionMark CSS bouncing tagged images is slower in Gecko with WebRender than with out

[jrmuizel]

From https://bugzilla.mozilla.org/show_bug.cgi?id=1395728

I see this running on my Mac

http://browserbench.org/MotionMark/developer.html?test-interval=30&display=minimal&tiles=big&controller=ramp&frame-rate=50&kalman-process-error=1&kalman-measurement-error=4&time-measurement=performance&suite-name=HTMLsuite&test-name=CSSbouncingtaggedimages&complexity=278

With WebRender I get 93.54 vs 279.69 without.

This seems like something that WebRender should be able to handle well.

[jrmuizel]

This is running with webrendest and layers-free turned on.

[jrmuizel]

Interestingly I get fallback blobs for the images when I run this on Linux.

[glennw]

Does that explain the performance issue? Or are you saying that you don't get painted layer on other platforms so there is a different issue there?

[jrmuizel]

It does not explain the performance issue. It seems slow on Linux and Mac (regardless of if the images show up as blob images or not).

[glennw]

OK, I'll do some profiling in both Servo and Gecko and report results here.

[jrmuizel]

Here's a standalone version: https://jrmuizel.github.io/perf-tests/motion-mark-tagged-images-still.html. I get 37 ms of GPU time with it.

[glennw]

@jrmuizel OK, in that standalone version I see 36ms in Gecko, and 3ms in Servo. I'll find out where the discrepancy is today.

[jrmuizel]

I suspect it's due to additional clips that gecko's doing

On Aug 31, 2017 7:08 PM, "Glenn Watson" [e-mail] wrote:

@jrmuizel https://github.com/jrmuizel OK, in that standalone version I
see 36ms in Gecko, and 3ms in Servo. I'll find out where the discrepancy is
today.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/servo/webrender/issues/1648#issuecomment-326444027,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAUTbc-TYvF682eeI9ObOuz43B76J9HAks5sdzz7gaJpZM4PJbUA
.

[glennw]

https://github.com/servo/webrender/pull/1649 drops the GPU time in Gecko from 36ms down to 5ms on my machine. This is still quite a bit higher than Servo, but makes it reasonable at least.

[jrmuizel]

So I tried to have a look at what the differences were between Servo and Gecko's display lists for this page. I wasn't able to get binary replay of recordings working from servo working so that made things more difficult. However, there were some differences:

1. Gecko has redundant clips: https://bugzilla.mozilla.org/show_bug.cgi?id=1396131
2. The bounds of the clips on the stacking contexts are smaller in servo's case

Manually removing the redundant clips did not seem to improve the performance so perhaps it's the clip bounds on the stacking context.

[jrmuizel]

Glenn, do you have some idea about what's happening differently between the
servo and gecko display lists?

[glennw]

I haven't looked further into it at this point. It's possible the 5ms vs 3ms difference may just be elsewhere (e.g. in the URL bar etc)?

[jrmuizel]

I meant the original large difference. Do you know if it was happening
because of the bounds on the stacking contexts? Would it be better if gecko
produced a display list more like servo?

On Sep 4, 2017 2:31 AM, "Glenn Watson" [e-mail] wrote:

I haven't looked further into it at this point. It's possible the 5ms vs
3ms difference may just be elsewhere (e.g. in the URL bar etc)?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/servo/webrender/issues/1648#issuecomment-326876950,
or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAUTbVKQg9vP3ELVcMX67q9IibHBEYXJks5se5lZgaJpZM4PJbUA
.

[glennw]

@jrmuizel Ah, I misread your question. It was happening because of the large clip regions (which may be a result of the stacking context bounds). It was really just a bug in WR, but as a general rule, the tighter the bounding rects and clip regions, the easier it is for WR.

[jrmuizel]

I reran this with #1649 which improved the performance significantly, but we're still slower than Gecko is.

[glennw]

OK, I'll investigate this further either tomorrow or early next week. Is #1649 landed in gecko master or were you testing with a local patch?

[jrmuizel]

1649 has made its way into mozilla-inbound but isn't in mozilla-central yet. When https://bugzilla.mozilla.org/show_bug.cgi?id=1396972 closes it will be in central.

FWIW, it's probably better to look at https://github.com/servo/webrender/issues/1670 as it's a real site and not a synthetic.

[glennw]

This test case is drawing a huge number of clip masks. Visually, there doesn't seem to be any reason it should be, so I need to investigate why.

[glennw]

OK, if I apply a local fix to avoid clip masks in this case, the MM score goes from 165 to 472 (!). I think that parts of https://github.com/servo/webrender/pull/2062/files provide a proper fix for this. @mrobinson is working on separating that into multiple commits, which I'm also going to test with locally to confirm it does solve this bug.

[glennw]

I think we can safely close this now - the score on my machine has gone from (initially) 165 to 472 with the fix above, and is now 598 when I run it on a current nightly. In all cases the backend, compositor and GPU times easily hold 60fps for the entire test.