Closed
Bug 1408421
Opened 8 years ago
Closed 8 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•8 years ago
|
||
It looks like this was introduced by 1365196
Reporter | ||
Comment 2•8 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•8 years ago
|
Blocks: stage-wr-nightly
status-firefox57:
--- → unaffected
status-firefox58:
--- → unaffected
Priority: -- → P2
Updated•8 years ago
|
Whiteboard: [wr-mvp]
Comment 3•8 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•8 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•8 years ago
|
Assignee: nobody → sotaro.ikeda.g
Flags: needinfo?(sotaro.ikeda.g)
Assignee | ||
Comment 5•8 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•8 years ago
|
||
Assignee | ||
Comment 7•8 years ago
|
||
Assignee | ||
Updated•8 years ago
|
Attachment #8924492 -
Flags: review?(jmuizelaar)
Updated•8 years ago
|
Status: NEW → ASSIGNED
Priority: P2 → P1
Reporter | ||
Comment 8•8 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•8 years ago
|
||
Apply the comment.
Attachment #8924492 -
Attachment is obsolete: true
Attachment #8924793 -
Flags: review+
Assignee | ||
Comment 10•8 years ago
|
||
Fixed nits.
Attachment #8924793 -
Attachment is obsolete: true
Attachment #8924794 -
Flags: review+
Comment 11•8 years ago
|
||
Pushed by sikeda@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/14a5ae97c682
Improving throttling GenerateFrame() r=jrmuizel
Comment 12•8 years ago
|
||
bugherder |
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
You need to log in
before you can comment on or make changes to this bug.
Description
•