Open
Bug 1467768
Opened 6 years ago
Updated 3 months ago
Reduce overhead/latency of applying async images
Categories
(Core :: Graphics: WebRender, enhancement, P2)
Tracking
()
NEW
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
Reporter | ||
Comment 3•6 years ago
|
||
No, we can probably do without fixing this for release.
Flags: needinfo?(kats)
Comment 4•6 years ago
|
||
With Bug 1476846, transaction update for video frames is sent fast if possible.
Updated•6 years ago
|
Assignee: sotaro.ikeda.g → nobody
Updated•2 years ago
|
Severity: normal → S3
Updated•3 months ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•