Painting blocked for 1+ minute
Categories
(Core :: Graphics: Canvas2D, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr115 | --- | unaffected |
firefox121 | --- | unaffected |
firefox122 | --- | unaffected |
firefox123 | --- | fixed |
firefox124 | --- | fixed |
People
(Reporter: florian, Unassigned)
References
(Regression)
Details
(Keywords: regression)
This seems to happen whenever I attempt to display this profile on an external screen. It happens consistently whenever I switch back to this tab when the window is maximized on my 4k screen. I saw it occasionally on the other screens, but not all the time.
Here's a profile of the hang: https://share.firefox.dev/3vyqml9
The compositor is blocked for for 1min21 in SetDisplayList.
I'm on 123.0a1 (2023-12-23) (64 bits) on Mac OS 14.2.1 (23C71). I tried restarting Firefox Nightly for an update, it didn't fix it (but looking at the build ID, it seems it didn't update me all the way to a current nightly). I tried turning off the external screens and then back on, it also didn't help. I haven't tried rebooting the macbook.
Reporter | ||
Comment 1•9 months ago
|
||
The most recent Nightly reproduces too: https://share.firefox.dev/4aQN8F5
Comment 2•9 months ago
|
||
This is probably caused by off main thread canvas.
Comment 3•9 months ago
|
||
Set release status flags based on info from the regressing bug 1829026
:lsalzman, since you are the author of the regressor, bug 1829026, could you take a look? Also, could you set the severity field?
For more information, please visit BugBot documentation.
Updated•9 months ago
|
Comment 4•9 months ago
|
||
Almost all of the time in the profile is spent blocked waiting on a RemoteTextureMap monitor. I think this is the same symptoms fixed in another bug, so if you are able to update the latest nightly, I would expect this to be better. I'm not sure why it isn't updating, that is puzzling.
Reporter | ||
Comment 5•9 months ago
|
||
(In reply to Andrew Osmond [:aosmond] (he/him) from comment #4)
if you are able to update the latest nightly, I would expect this to be better. I'm not sure why it isn't updating, that is puzzling.
In comment 1 I have a profile from the 20240111210611 Nightly, is there a bug that has been fixed since that?
Comment 6•9 months ago
|
||
I am just making a stab in the dark based on a hunch in bug 1874534, that this may be related to some variation of context loss bugs. If that is the case, when bug 1874534 lands, it may help fix it. You could try one of the builds from autoland to see if it helps any: https://treeherder.mozilla.org/jobs?repo=autoland&revision=21be69951c962d3833d7117f56c2909b20b3d841
Reporter | ||
Comment 7•9 months ago
|
||
Still seeing hangs today: https://share.firefox.dev/48vSeoH on the 20240114211039 build.
Reporter | ||
Comment 8•9 months ago
|
||
Profile following more closely the steps I gave in comment 0 (ie. switch to a tab containing a large profile, in a window that's maximized on the 4k screen) : https://share.firefox.dev/4b09Cn1
I notice:
- "Runnable - PWebRenderBridge::Msg_SetDisplayList" takes 29+s on the Compositor thread.
- The "RefreshDriverTick waiting for paint" markers seem to continue forever in the content process main thread.
Comment 9•9 months ago
|
||
Moving to component Canvas2D
based on evidence.
Comment 10•9 months ago
|
||
Set release status flags based on info from the regressing bug 1829026
Comment 11•8 months ago
•
|
||
There is a possibility this is a dup of bug 1876506, though I was never successful at reproducing the bug here to investigate this further. Bug 1876506 happened because of certain acceleration failure scenarios that require canvases exceeding a certain size (5280) and could cause composition failures leading to hangs.
Florian, can you see if the latest nightly, where the fix for bug 1876506 landed, fixes this issue for you?
Reporter | ||
Comment 12•8 months ago
|
||
I can no longer reproduce in today's nightly, so I'll go ahead and close as a duplicate of bug 1876506. Thanks!
While trying to reproduce today, I encountered very visible flicker (that after investigation turned out to be unrelated; I filed bug 1877153), and jank (see these profiles: https://share.firefox.dev/3vPEJSh https://share.firefox.dev/49btWA7 In both of them, the parent main thread is blocked on PCompositorBridge::Msg_FlushRendering sync IPCs. I have not filed a bug as I haven't found steps to reproduce on a clean Firefox profile, but maybe the profiles will give you hint about whether there's something interesting to look into).
Updated•8 months ago
|
Updated•8 months ago
|
Description
•