1421543 - Retain webrender commands

Status: RESOLVED WONTFIX

(Core :: Graphics: WebRender, enhancement, P3)

Description

[Ethan Lin[:ethlin]]

The time of render backend and displaylist IPC is proportional to the number of display items. So for some complicated pages or performance test pages, backend and IPC always slow down the performance.
Luckily, gecko retained DL is already turned on by default in Nightly. We should take the advantage of retained DL and use the result when we are creating webrender commands.
To retain webrender commands, the render backend should keep the last webrender commands. And we can know which display items are changed, added, or deleted. So we just update the necessary WR commands to render backend. In the future, we should build scene incrementally from the modified webrender commands.

MotionMark[1] and MazeSolver[2] are both good examples. The gecko profiler result (I applied bug 1421054 patch):
one of the test in MotionMark: https://perfht.ml/2AiJFhA
MazeSolver: https://perfht.ml/2AjwTzv


[1] http://browserbench.org/MotionMark/developer.html
[2] https://testdrive-archive.azurewebsites.net/Performance/MazeSolver/Default.html

Comment 1

[Ethan Lin[:ethlin]]

I think it's important since many websites(like facebook, some talos tests) have this problem. About implementation, I just know how to get the display item changes on the content side. For webrender, we probably need to set a id for each WR item first. WR should provide the interface to add/delete/update an item. We may also need to retain the clip_scroll_tree.
I know the whole thing may not be easy. If possible, we could have a prototype first. Jeff, kats, could you give me some suggestions?

Comment 2

[Jeff Muizelaar [:jrmuizel]]

It looks like your profiles are from a browser where the rust code is built without optimization. To get the best results make sure you're building with rust 1.22 at opt-level 3 (Currently even nightly builds are still built with rust 1.21 and at opt-level 2)

That being said, I'd like to avoid the complexity of doing any kind of retaining of webrender display lists without solid evidence that we need to.

When I look at profiles today we're usually spending more time building Gecko display list than the webrender one. Let's see how things look after https://github.com/servo/webrender/pull/2128 and we remove the copy that happens because bug 1379680 hasn't landed yet.

If we need to, I think there are still gains to be had when building the complete display list. It has been less of a priority because we tend to be bottlenecked on other parts of the pipeline right now.

Comment 3

[Nicolas Silva [:nical]]

This will be fixed by Glenn's displaylist bypass