Send transactions directly to the scene builder thread when possible
Categories
(Core :: Graphics: WebRender, enhancement, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox82 | --- | fixed |
People
(Reporter: nical, Assigned: nical)
References
(Blocks 1 open bug)
Details
(Whiteboard: wr-planning)
Attachments
(17 files, 3 obsolete files)
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review |
Currently transactions that trigger scene building first go through the render backend, then some resources are collected (font, blobs) and sent to the scene builder. If the render backend is busy this delays the scene being processed, causing extra latency for layout transactions.
With ipc_channel removed, we can move the few hash maps on that store data we send to the scene builder, keep them at the API level instead and send messages directly to the scene builder. It should make things simpler (no need to remember which data is pre/post scene building on the render backend, everything is post-scene building) and reduce latency in some cases.
Assignee | ||
Comment 1•5 years ago
|
||
This is a small preliminary refactoring that will be needed to let the api talk to the scene builder thread.
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 2•5 years ago
|
||
Now that the capture code is gone, we don't use these serde implementations. They get in the way of changing the way transactions are represented so I'd like to remove a bunch of them for now.
Assignee | ||
Comment 3•5 years ago
|
||
The goal is to move this code out of the render backend to avoid requiring the messages to transit through this thread. Other similar changes are in progress.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 5•5 years ago
|
||
DocumentView has a mix of members that affect scene building and memebers that change frame to frame. These need to be updated at different rates and more importantly follow the respective flow of scene and frame transactions, which wasn't done properly before this change.
Depends on D71781
Assignee | ||
Comment 6•5 years ago
|
||
The information comes with SetDisplayList messages but was applied before scene building instead of during scene swap, which breaks the transaction model and looks like a bug.
Assignee | ||
Comment 7•5 years ago
|
||
Comment 8•5 years ago
|
||
bugherder |
Comment 10•5 years ago
|
||
bugherder |
Comment 11•5 years ago
|
||
Assignee | ||
Comment 12•5 years ago
|
||
Comment 13•5 years ago
|
||
bugherder |
Assignee | ||
Comment 14•5 years ago
|
||
Turns out we sometimes send transactions that don't change anything (for example in reftests we continuously set the quality setting to the same value) which can trigger unnecessary scene building. In reftests this causes us to build a scene after removing font instances that it refers to.
Assignee | ||
Comment 15•5 years ago
|
||
This requires pulling FrameBuilderConfig and a few other types along which isn't very satisfying but oh well.
Assignee | ||
Comment 16•5 years ago
|
||
This patch separates SceneBuilderRequest into two enums: One we'll be able to send from the api, and containing types that shouldn't move to the webrender_api crate. For example LoadScene depends on the Scene struct and at this point a quarter of webrender's types would need to move to webrender_api.
This solution is a bit iffy but I'm not sure how to better do this. If we don't need strict ordering, moving to crossbeam's queue which support select would let us at least avoid sending dummy BackendMessage to instruct the scene builder thread to look into the other queue.
This patch should not change the current behavior except for one (important) detail: all messages that use BackendSceneBuilderMessage have to go through the low priority scene queue instead of the high priority one. This affects the capture stuff, I think that it's still correct but I'm not familiar enough with it to be sure.
Comment 17•5 years ago
|
||
https://github.com/servo/webrender/pull/3936 adds the Serialize/Deserialize that allow Servo to build with the master revision of the webrender git repository. This will shortly be broken again by https://phabricator.services.mozilla.com/D72397 if that revision lands and syncs upstream.
Assignee | ||
Comment 18•5 years ago
|
||
This prevents the request from racing ahead of the AddFontInstance message which follows the transaction through the scene builder thread and silently returning zero-sized glyphs.
Updated•5 years ago
|
Assignee | ||
Comment 19•5 years ago
|
||
One of the last steps towards letting the api send scene building requests directly. I'll clean up the names after everything is in place.
Depends on D72614
Assignee | ||
Comment 20•5 years ago
|
||
This change allows the api to talk directly to the scene builder thread. This avoids unpredictable and sometimes large latency caused by scene builder requests sitting in a busy render backend's event loop.
Depends on D72906
Assignee | ||
Comment 21•5 years ago
|
||
Assignee | ||
Comment 22•5 years ago
|
||
This was split off from https://phabricator.services.mozilla.com/D71992
Depends on D74293
Assignee | ||
Comment 23•5 years ago
|
||
Depends on D74296
Assignee | ||
Comment 24•5 years ago
|
||
Depends on D74297
Assignee | ||
Comment 25•5 years ago
|
||
Depends on D74298
Assignee | ||
Comment 26•5 years ago
|
||
Depends on D74299
Assignee | ||
Comment 27•5 years ago
|
||
Depends on D74300
Comment 28•4 years ago
|
||
Comment 29•4 years ago
|
||
bugherder |
Comment 30•4 years ago
|
||
bugherder |
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 31•4 years ago
|
||
Comment 32•4 years ago
|
||
Comment 33•4 years ago
|
||
bugherder |
Comment 34•4 years ago
|
||
Comment 35•4 years ago
|
||
bugherder |
Comment 36•4 years ago
|
||
== Change summary for alert #26001 (as of Wed, 20 May 2020 03:49:19 GMT) ==
Improvements:
3% raptor-tp6-yahoo-mail-firefox-cold fcp linux64-shippable-qr opt 334.50 -> 324.75
For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=26001
Comment 37•4 years ago
|
||
Comment 38•4 years ago
|
||
bugherder |
Comment 39•4 years ago
|
||
Assignee | ||
Updated•4 years ago
|
Comment 41•4 years ago
|
||
bugherder |
Comment 42•4 years ago
•
|
||
== Change summary for alert #26927 (as of Mon, 14 Sep 2020 10:58:35 GMT) ==
Improvements:
8% displaylist_mutate windows10-64-shippable-qr opt e10s stylo 2,785.92 -> 2,559.58
6% displaylist_mutate windows10-64-shippable-qr opt e10s stylo 2,747.33 -> 2,574.94
4% displaylist_mutate linux64-shippable-qr opt e10s stylo 2,962.74 -> 2,854.00
For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=26927
Description
•