All content processes are notified of PCompositorBridge::Msg_DidComposite
Categories
(Core :: Graphics: WebRender, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox88 | --- | fixed |
People
(Reporter: florian, Assigned: sotaro)
References
(Blocks 4 open bugs)
Details
(Keywords: perf-alert, power)
Attachments
(1 file)
Compositing happens at 60Hz (I don't know why; I filed bug 1690619 to see if we could collect more information about it), and all content processes receive PCompositorBridge::Msg_DidComposite
messages (see the Runnable markers).
This alone uses a bit more than 1% of a core per content process.
Comment 1•5 years ago
|
||
This is a regression in WebRender compared to non-WebRender.
Same open tabs, WR: https://share.firefox.dev/3twpSGX Non-WR: https://share.firefox.dev/3oLztGf
Non-WebRender only notified visible tabs.
Updated•5 years ago
|
Comment 2•5 years ago
|
||
Testcase: attachment 9089778 [details]
Updated•4 years ago
|
Assignee | ||
Comment 3•4 years ago
•
|
||
The problem seems to happen because DidComposite is notified to all clients that was notified by RendererOGL::FlushPipelineInfo().
It seems that CompositorBridgeParent::NotifyPipelineRendered() need to send DidComposite to client only when it is necessary.
Assignee | ||
Comment 4•4 years ago
|
||
Assignee | ||
Comment 5•4 years ago
|
||
Updated•4 years ago
|
Comment 7•4 years ago
|
||
bugherder |
Comment 8•4 years ago
|
||
== Change summary for alert #28900 (as of Wed, 24 Feb 2021 06:53:45 GMT) ==
Improvements:
Ratio | Suite | Test | Platform | Options | Absolute values (old vs new) |
---|---|---|---|---|---|
6% | tart | linux1804-64-shippable-qr | e10s stylo webrender-sw | 3.91 -> 3.67 | |
4% | tp5o_scroll | linux1804-64-shippable-qr | e10s stylo webrender-sw | 2.14 -> 2.06 |
For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=28900
Updated•4 years ago
|
Updated•3 years ago
|
Description
•