Closed Bug 1482212 Opened 7 years ago Closed 3 years ago

Understand Shield study COMPOSITE_TIME results

Categories

(Core :: Graphics: WebRender, enhancement, P3)

63 Branch
enhancement

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.
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)
As Matt points out accumulation also happens in FrameRenderingComplete() so my previous idea was garbage.
Flags: needinfo?(sotaro.ikeda.g)
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.
Priority: -- → P2
Priority: P2 → P3
Blocks: stage-wr-next
No longer blocks: stage-wr-trains

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.