Closed Bug 1372409 Opened 4 years ago Closed 4 years ago
Webrender can get stuck in a compositing loop
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.
There were 2 causes of this bug.  There is a case that no new transaction from WebRenderLayerManager. DiscardCompositorAnimations() is called in the beginning of WebRenderLayerManager::EndTransactionInternal()  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.
Bug 1372816 handles .
4 years ago
See Also: → 1372066
I did not see , since Bug 1372816 was addressed.
:mstange, can you confirm if this bug is fixed?
I can no longer reproduce this bug. Looks like it's fixed, thanks!
You need to log in before you can comment on or make changes to this bug.