runUiThreadCallback blocks main thread for 294ms (Moto G5) w/ 75ms in copyPixelsFromBuffer (due to screenshots?)
Categories
(Core :: Graphics, defect, P3)
Tracking
()
People
(Reporter: mcomella, Unassigned)
References
Details
In bug 1693911 comment 6, we discovered runUiThreadCallback blocks the main thread for 294ms in a profile on my Moto G5, COLD VIEW. runUiThreadCallback calls into Bitmap.copyPixelsFromBuffer for 75ms. Here's the profile: https://share.firefox.dev/2SkLiZA
This occurs at an arbitrary point after start up but it appears to occur after visual completeness and possibly after DOMComplete. As such, I'm not too concerned about it so we can probably set it to a low priority but if the user happens to interact during this period, their interaction would be delayed by a user perceptible duration which is why I filed anyway.
In bug 1693911 comment 7, :jnicol threw out ideas about the root cause and possible solutions. iiuc, one of these is that we're taking a screenshot that causes the delay. The fact that this delay does not appear in COLD MAIN backs this up (because we have no need to take GeckoView screenshots in COLD MAIN). Also, I notice that the front-end code requests a screenshot shortly before the delay occurs: https://share.firefox.dev/3r7Qv3Q
:jnicol, does this sound like an issue the graphics team would want to prioritize? If so, do you want me to test this screenshot theory by removing the front-end code that requests a screenshot?
fwiw, I took a profile without the profiler screenshots feature (i.e. the front-end code still gets a screenshot) and still see it: https://share.firefox.dev/3r6ck3Q but I'd expect this given the explanation above.
|
Reporter | |
Comment 1•4 years ago
|
||
runUiThreadCallback actually calls copyPixelsFromBuffer twice in that profile: I wonder if they are related?
|
||
Updated•4 years ago
|
Description
•