Open Bug 1467768 Opened 6 years ago Updated 3 months ago

Reduce overhead/latency of applying async images

Categories

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

Other Branch
enhancement

Tracking

()

People

(Reporter: kats, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [gfx-noted])

Fix this TODO: https://searchfox.org/mozilla-central/rev/c621276fbdd9591f52009042d959b9e19b66d49f/gfx/layers/wr/WebRenderBridgeParent.cpp#1399

This should be a relatively simple matter of adding a bool parameter to ApplyAsyncImages that indicates whether new display lists are allowed. We will then call ApplyAsyncImages twice: at the current call site at [1] we call it with the "allow display lists" flag, and send that transaction to the scene builder thread. And then we would call it again on the other transaction at [2], with the "disallow display lists" flag and that transaction will get handled directly on the render backend thread.

The implementation of the ApplyAsyncImages function would also need to be updated so that it computes |updateDisplayList| at the start of the loop iteration, before touching aTxn, and then only updates aTxn if the updateDisplayList variable matches the "allow display lists" argument.

However, we might also want to do the equivalent of bug 1467765 comment 0 for async images - that is, instead of sampling the async image at the time that we create and send the GenerateFrame transaction on the compositor thread, we might want to sample the async images as part of the sampling step on the render backend thread to get the very latest image.

[1] https://searchfox.org/mozilla-central/rev/c621276fbdd9591f52009042d959b9e19b66d49f/gfx/layers/wr/WebRenderBridgeParent.cpp#1406
[2] https://searchfox.org/mozilla-central/rev/c621276fbdd9591f52009042d959b9e19b66d49f/gfx/layers/wr/WebRenderBridgeParent.cpp#1427
I take a look.
Assignee: nobody → sotaro.ikeda.g
Depends on: 1475187
No longer depends on: 1475187
Depends on: 1476846
Kats, do we need this for release?
Flags: needinfo?(kats)
No, we can probably do without fixing this for release.
Blocks: stage-wr-next
No longer blocks: stage-wr-trains
Flags: needinfo?(kats)
Depends on: 1477608
With Bug 1476846, transaction update for video frames is sent fast if possible.
Assignee: sotaro.ikeda.g → nobody
Severity: normal → S3
Blocks: wr-todos
No longer blocks: stage-wr-next, 1455591
You need to log in before you can comment on or make changes to this bug.