Closed
Bug 1408421
Opened 5 years ago
Closed 5 years ago
RenderBackend thread does not overlap cpu time with the Render thread
Categories
(Core :: Graphics: WebRender, defect, P1)
Core
Graphics: WebRender
Tracking
()
RESOLVED
FIXED
mozilla58
Tracking | Status | |
---|---|---|
firefox57 | --- | unaffected |
firefox58 | --- | unaffected |
People
(Reporter: jrmuizel, Assigned: sotaro)
References
Details
(Whiteboard: [wr-mvp])
Attachments
(1 file, 2 obsolete files)
7.82 KB,
patch
|
sotaro
:
review+
|
Details | Diff | Splinter Review |
You can see it in this profile of gmail: https://perfht.ml/2kNsK2u
Reporter | ||
Comment 1•5 years ago
|
||
It looks like this was introduced by 1365196
Reporter | ||
Comment 2•5 years ago
|
||
Bug 1365196 was added to prevent us from over producing frames. Perhaps the right solution is to only allow one extra frame.
Updated•5 years ago
|
Blocks: stage-wr-nightly
status-firefox57:
--- → unaffected
status-firefox58:
--- → unaffected
Priority: -- → P2
Updated•5 years ago
|
Whiteboard: [wr-mvp]
Comment 3•5 years ago
|
||
If I changed the maxPendingFrameCount to 2, the scrolling looks better on windows. [1]http://searchfox.org/mozilla-central/source/gfx/layers/wr/WebRenderBridgeParent.cpp#1144
Comment 4•5 years ago
|
||
Actually Bug 1382132 changed the maxPendingFrameCount from 2 to 1. For APZ with WR, it costs time for build_scene because of bug 1408174. I believe we can get benefit from rendering pipeline if we change the maxPendingFrameCount as 2 for scrolling. Sotaro, any thoughts?
Flags: needinfo?(sotaro.ikeda.g)
Assignee | ||
Updated•5 years ago
|
Assignee: nobody → sotaro.ikeda.g
Flags: needinfo?(sotaro.ikeda.g)
Assignee | ||
Comment 5•5 years ago
|
||
When maxPendingFrameCount was set to 2, there was cases that frame latency became too big. One example was that render thread always had 2 pending rendering frames. It could happen when rendering take very long. Another example was that background thread thread always had 2 pending frames. It could happen when background thread was too busy. To avoid these situation, I set maxPendingFrameCount to 1. But it restricts too much. We need to improve the performance by minimizing the latency. Just changing maxPendingFrameCount to 2 could not achieve it.
Assignee | ||
Comment 6•5 years ago
|
||
Assignee | ||
Comment 7•5 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=b33c6143bbf4536f82fbedd0070abbf9329d55ea
Assignee | ||
Updated•5 years ago
|
Attachment #8924492 -
Flags: review?(jmuizelaar)
Updated•5 years ago
|
Status: NEW → ASSIGNED
Priority: P2 → P1
Reporter | ||
Comment 8•5 years ago
|
||
Comment on attachment 8924492 [details] [diff] [review] patch - Improving throttling GenerateFrame() Review of attachment 8924492 [details] [diff] [review]: ----------------------------------------------------------------- ::: gfx/webrender_bindings/RenderThread.cpp @@ +265,5 @@ > return renderer->Resume(); > } > > +bool > +RenderThread::TooMuchPendingFrames(wr::WindowId aWindowId) TooManyPendingFrames()
Attachment #8924492 -
Flags: review?(jmuizelaar) → review+
Assignee | ||
Comment 9•5 years ago
|
||
Apply the comment.
Attachment #8924492 -
Attachment is obsolete: true
Attachment #8924793 -
Flags: review+
Assignee | ||
Comment 10•5 years ago
|
||
Fixed nits.
Attachment #8924793 -
Attachment is obsolete: true
Attachment #8924794 -
Flags: review+
Comment 11•5 years ago
|
||
Pushed by sikeda@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/14a5ae97c682 Improving throttling GenerateFrame() r=jrmuizel
Comment 12•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/14a5ae97c682
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
You need to log in
before you can comment on or make changes to this bug.
Description
•