Move the pending scene data structure to the SceneBuilder thread #2998

nical · 2018-08-30T16:04:06Z

This PR reorganizes the code in the render backend and scene builder such that:

The render backend now only manages a single scene per document: the one it can use for frame building.
The scene builder now manages a scene per document and uses it to generate the FrameBuilder.
The render backend sends to the scene builder thread the events it needs to keep the Scene data structure up to date.
Transactions have been consolidated around 3 structs: TransactionMsg is what the API sends to the render backend, Transaction is what the render backend creates and sends to the scene builder thread(s), and BuiltTransaction is what the scene builder sends back to the render backend after scene building. These three structs represent the same thing but at different stages of the pipeline.
A lot of code was simplified (for example no more calling update_document twice with different parameters before and after scene building to have it do different things)

This change is needed in order to get the low priority scene building in #2989 to work without requiring extra handshakes between the scene builder and the render backend threads.

This is rebased on top of #2992.

This change is

nical · 2018-08-30T16:07:37Z

I am so sorry for this wall of code. Most of it is moving things around. I think that the code is quite a bit easier to understand after this change than before but the diff view doesn't do it justice. You can ignore the first 5 commits which are from #2992.

nical · 2018-08-30T16:25:54Z

webrender/src/scene_builder.rs

 use time::precise_time_ns;

+/// Represents the work associated to a transaction before scene building.
+pub struct Transaction {


Whether splitting the data in Transaction into a lot of vectors the best is up for debate, here is a bit of context:
I realize that having a bunch of small vectors means a bunch of small allocations, however:

This representation made it easy to do a few of things in this PR such as knowing whether the transaction needs triggers a scene build and whether it can skip the scene builder by simply looking at which vectors are empty.

It will simplify the problem of merging transaction whenever we get to implementing that. Right now if scene building takes a long time, requests can accumulate faster than they are processed which leads to growing delay between user input and rendering which is awful. I want to be able to take several transactions and merge them into one that accumulates the important states while discarding redundant or out of date changes. This is a easier to do if things are organized this way than with a single vector.


        Move the pending scene data structure to the scene builder thread.

With this change the render backend only sees the state of the scene that it can use for frame building and the scene builder thread manages its own scene. This will allow us to perform low priority scene building and rasterization asynchronously without having to involve the render backend thread.


        Remove the per-document FrameBuilderConfig.

All documents currently always have the same config.


        Move scene loading code behind the "replay" feature flag.


        Fix confusion with generate frame/render/composite terminology.

From now on, generate frame means having the frame builder generate a frame (but not necessarily render it), and render means asking the renderer to render a frame.

nical · 2018-08-31T14:46:09Z

I added a commit that simplifies the terminology around generating frames and rendering (and fixes a bug I caused because of the associated confusion)

Before this PR:

render meant building a frame with the frame builder but not necessarily asking the renderer to render it.
composite meant asking the renderer to render.

After this PR:

generate_frame means asking the frame builder to build a frame.
render means asking the renderer to render a frame.

nical · 2018-08-31T15:57:21Z

try push looks good so far: https://treeherder.mozilla.org/#/jobs?repo=try&revision=e606386b9e899fcde16d8344fdc8c5ddaaf9e6e3

The push has all of the commits since the last WR update so I can't take credit for the unexpected passes. There are also a few failures with rendering differences within fuzzing range and I don't think these can be the result of this PR.

kvark

Reviewed 4 of 4 files at r3.
Reviewable status: all files reviewed, 8 unresolved discussions (waiting on @kvark and @nical)

webrender/src/render_backend.rs, line 332 at r3 (raw file):

struct DocumentOps {
    scroll: bool,
    generate_frame: bool,

I'd marginally prefer us to be consistent with the rest of the internal code and call this build_frame (and possibly rename the GenerateFrame message as well).

webrender/src/render_backend.rs, line 333 at r3 (raw file):

    scroll: bool,
    generate_frame: bool,
    render: bool,

uuh, so we have an old flag with an entirely new semantics now
would be safer to rename it as well, e.g. show_frame to avoid confusion

webrender/src/render_backend.rs, line 529 at r3 (raw file):

                profile_scope!("SetRootPipeline");

                txn.set_root_pipeline = Some(pipeline_id);

I am slightly confused here at a high level: we receive a scene message for updating the document, but then some of the updates affect Transaction and others affect Document itself. Seems like a recipe for synchronization issues?

webrender/src/render_backend.rs, line 594 at r3 (raw file):

                            replace(&mut txn.rasterized_blobs, Vec::new())
                        );
                        if let Some(rasterizer) = txn.blob_rasterizer.take() {

why are we taking out the blob rasterizer?

webrender/src/render_backend.rs, line 828 at r3 (raw file):

        profile_counters: &mut BackendProfileCounters,
    ) {
        let mut txn = Box::new(Transaction {

why are we boxing the transaction?

webrender/src/render_backend.rs, line 940 at r3 (raw file):

        // rebuild the hit-tester, so we trigger a frame generation
        // step.
        generate_frame |= has_built_scene;

we might need a separate flag for hit tester info update, given that it shouldn't need the full frame build

webrender/src/scene.rs, line 193 at r3 (raw file):

    pub fn has_root_pipeline(&self) -> bool {
        if let Some(ref root_id) = self.root_pipeline_id {

nit: this could look cleaner without a return

webrender/src/scene_builder.rs, line 22 at r2 (raw file):

Previously, nical (Nicolas Silva) wrote…

Whether splitting the data in Transaction into a lot of vectors the best is up for debate, here is a bit of context:
I realize that having a bunch of small vectors means a bunch of small allocations, however:

This representation made it easy to do a few of things in this PR such as knowing whether the transaction needs triggers a scene build and whether it can skip the scene builder by simply looking at which vectors are empty.

It will simplify the problem of merging transaction whenever we get to implementing that. Right now if scene building takes a long time, requests can accumulate faster than they are processed which leads to growing delay between user input and rendering which is awful. I want to be able to take several transactions and merge them into one that accumulates the important states while discarding redundant or out of date changes. This is a easier to do if things are organized this way than with a single vector.

Does gecko has facilities implemented/planned for accelerating those heap allocations? We have accumulated quite a big technical debt in performance, partly because of those allocations, and I want to see the light at the end of this tunnel.

nical

Reviewable status: all files reviewed, 8 unresolved discussions (waiting on @nical)

webrender/src/render_backend.rs, line 332 at r3 (raw file):