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•3 years ago
|
| Assignee | ||
Comment 1•3 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•3 years ago
|
||
Another profile showing the same behavior: https://share.firefox.dev/3BtvQO7
| Assignee | ||
Comment 3•3 years ago
|
||
Updated•3 years ago
|
Comment 5•3 years ago
|
||
| bugherder | ||
Updated•2 years ago
|
Description
•