Closed Bug 1372409 Opened 4 years ago Closed 4 years ago

Webrender can get stuck in a compositing loop

Categories

(Core :: Graphics: WebRender, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla56
Tracking Status
firefox54 --- unaffected
firefox55 --- unaffected
firefox56 --- fixed

People

(Reporter: mstange, Assigned: sotaro)

References

Details

Steps to reproduce:
 1. Enable webrender, webrendest and the webrender profiler.
 2. Go to https://bugzilla.mozilla.org/show_bug.cgi?id=1372299
 3. In one swift motion, move your mouse over the link to the first attachment and click it.

Expected results:
As soon as the new page has loaded, we should stop compositing and the profiler overlay should come to a rest.

Actual results:
We keep compositing at 60fps, forever.


This does not happen if I rest my mouse on the link for a bit before I click the link.

I think this somehow has to do with the link target overlay in the bottom left corner of the window. It animates in and out as your mouse moves over links. If you click a link, maybe the animation is aborted before it's completed, and that causes us to think that there is still an animation running?
I could reproduce the problem.
Assignee: nobody → sotaro.ikeda.g
Looks like this is related to OMTA. The high cpu usage was gone after change gfx.webrender.omta.enabled as 0.
Depends on: 1372799
No longer depends on: 1372799
There were 2 causes of this bug.
[1] There is a case that no new transaction from WebRenderLayerManager. 
      DiscardCompositorAnimations() is called in the beginning of WebRenderLayerManager::EndTransactionInternal()
[2] At WebRenderBridgeParent, TOpAddCompositorAnimations was received after the animation removal.
      The TOpAddCompositorAnimations was added during EmptyTransaction.
      But the transaction was aborted by TransactionIncomplete. After that, the animation was removed.
      Then WebRenderLayerManager did a new EndTransaction(), it triggered to send the TOpAddCompositorAnimations.
Depends on: 1372816
Bug 1372816 handles [2].
I did not see [1], since Bug 1372816 was addressed.
:mstange, can you confirm if this bug is fixed?
Flags: needinfo?(mstange)
I can no longer reproduce this bug. Looks like it's fixed, thanks!
Status: NEW → RESOLVED
Closed: 4 years ago
Flags: needinfo?(mstange)
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
You need to log in before you can comment on or make changes to this bug.