compositor animations seems to be running in a closed window in this profile
Categories
(Core :: Graphics: WebRender, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox111 | --- | fixed |
People
(Reporter: florian, Assigned: florian)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
I was asked for help in bug 1788800. I looked at a profile (https://share.firefox.dev/3Ufu1eq generated with ./mach test browser/components/firefoxview/tests/browser/browser_colorways_card.js --verify --profiler
).
What I saw in the profile is:
- vsync remains enabled, we have composite and SampleAnimation markers.
- there are no new CompositorScreenshot markers during that time, so somehow the graphics code knows the window is already closed.
- the screenshot tracks end and vsync gets disabled (letting the test finish) after a GCMajor marker.
My impression is that a window is closed but JS code keeps the DOM Window object alive until a GC Major occurs. This happens several seconds later, during which we still do a lot of work for CSS compositor animations (a background-color property was animated in this case).
Can we ensure that all compositor resources (including off-main-thread animations) are cleaned up when a window is closed? In this case, the animation seems to stop once the GC runs, but can we make it happen sooner? (so that we also cover the case where a reference to the window object is permanently leaked)
Updated•2 years ago
|
Assignee | ||
Comment 1•2 years ago
|
||
Note: the patch landed yesterday in bug 1788800 changed the behavior of the test, so to reproduce the bug you need to use the version of the test before the patch.
Assignee | ||
Comment 2•2 years ago
|
||
Another profile showing the same behavior: https://share.firefox.dev/3BtvQO7
Assignee | ||
Comment 3•2 years ago
|
||
Updated•2 years ago
|
Comment 5•2 years ago
|
||
bugherder |
Updated•7 months ago
|
Description
•