Closed
Bug 1482212
Opened 7 years ago
Closed 3 years ago
Understand Shield study COMPOSITE_TIME results
Categories
(Core :: Graphics: WebRender, enhancement, P3)
Tracking
()
RESOLVED
WONTFIX
| Tracking | Status | |
|---|---|---|
| firefox63 | --- | affected |
People
(Reporter: jrmuizel, Unassigned)
References
Details
The current results are somewhat surprising. We should figure out the cause of the difference.
| Reporter | ||
Comment 1•7 years ago
|
||
It looks like WebRender only contributes to this metric when for nop frames as DecPendingFrameCount(aWindowId) is only called from wr_notifier_nop_frame_done. Thoughts Sotaro?
Flags: needinfo?(sotaro.ikeda.g)
| Reporter | ||
Comment 2•7 years ago
|
||
As Matt points out accumulation also happens in FrameRenderingComplete() so my previous idea was garbage.
Flags: needinfo?(sotaro.ikeda.g)
Comment 3•7 years ago
|
||
wr_notifier_nop_frame_done() is rarely used. It is used in the following situation
- RenderBackend handles frame generation and calls notifier.new_frame_ready but it does not have root_pipeline_id.
- RenderBackend handles frame generation and calls notifier.new_frame_ready but document is not ready for render yet.
this happens if we are building the first scene asynchronously and scroll at the same time.
Then wr_notifier_new_frame_ready() is normally used. When I tested locally on linux and win10, I did not saw wr_notifier_nop_frame_done() call.
| Reporter | ||
Updated•7 years ago
|
Priority: -- → P2
Updated•7 years ago
|
Blocks: stage-wr-trains
Updated•7 years ago
|
Priority: P2 → P3
| Reporter | ||
Updated•6 years ago
|
Comment 4•3 years ago
|
||
Probably no longer relevant.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•