1786247 - Theme with animated gif background has a steady memory leak when window is completely covered by another window

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect, P3)

Description

[Kestrel]

STR:

1. Start with MOZ_ENABLE_WAYLAND=1 on Ubuntu 22.04 (GNOME 42.2).
2. Install a theme with a large animated gif background like Dark Space.
3. Open two windows and completely cover one with the other window.

Total system memory usage climbs steadily when window is completely covered and only released when it becomes visible. It is not attributed to any Firefox process in about:processes or the system Task Manager but can be measured in about:memory gfx section of main process.

It does not happen with widget.wayland.vsync.enabled = false or if the window is minimized, on a different workspace or covered by a different application.

Regression window:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=69e6477b290b4f6d2beffffd3520e07d51685182&tochange=d9b0105477475ee9d411fdd67d37b1774aedb3da

Regressed by Bug 1629140.

5,667,318,356 B (100.0%) -- gfx
└──5,667,318,356 B (100.0%) -- webrender
   ├──2,951,682,644 B (52.08%) -- textures
   │  ├──2,719,208,644 B (47.98%) ── render-texture-hosts
   │  ├────100,663,296 B (01.78%) ── render-targets
   │  ├─────87,293,952 B (01.54%) -- texture-cache
   │  │     ├──87,293,952 B (01.54%) ── atlas
   │  │     └───────────0 B (00.00%) ── standalone
   │  ├─────22,201,744 B (00.39%) ── swap-chains
   │  ├─────16,777,216 B (00.30%) ── depth-targets
   │  ├──────2,785,280 B (00.05%) ── gpu-cache
   │  ├──────2,752,512 B (00.05%) ── vertex-data
   │  ├──────────────0 B (00.00%) ── picture-tiles
   │  ├──────────────0 B (00.00%) ── texture-upload-pbos
   │  └──────────────0 B (00.00%) ── upload-staging-textures
   └──2,715,635,712 B (47.92%) -- images/mapped_from_owner
      ├──2,710,929,408 B (47.83%) -- pid=3271
      │  ├──2,703,052,800 B (47.70%) ── image(640x360, compositor_ref:2, creator_ref:1)/decoded-other [2933]
      │  ├──────6,451,200 B (00.11%) ── image(640x360, compositor_ref:1, creator_ref:1)/decoded-other [7]
      │  ├────────921,600 B (00.02%) ── image(640x360, compositor_ref:26, creator_ref:1)/decoded-other

Comment 1

[Robert Mader [:rmader]]

Uh, interesting. This is a specialty of the Wayland vsync source approach and can probably be fixed by implementing bug 1695227

Comment 2

[Robert Mader [:rmader]]

For the record: do I understand correctly that the memory is not leaked, but just "queued" until the window is visible again?

Comment 3

[Kenny Levinsen :kennylevinsen]

Why would a stalled VsyncSource lead to accumulated unreleased memory for an obscured window? Stuff generated on a different timer that is only released on a VsyncSource tick? :/

Comment 4

[Robert Mader [:rmader]]

(In reply to Kenny Levinsen :kennylevinsen from comment #3)

Why would a stalled VsyncSource lead to accumulated unreleased memory for an obscured window? Stuff generated on a different timer that is only released on a VsyncSource tick? :/

Yeah, something like that...I think stalled VsyncSource is simply not expected in other parts of the stack - the renderer should get suspended instead. The Wayland one it AFAIK the only one where this can happen for longer periods. But this shouldn't be hard to fix with some timeout or so.

Comment 5

[Pascal Chevrel:pascalc (PTO until April 26)]

Robert, do you intend to work on this bug or should we find an owner?

Comment 6

[Robert Mader [:rmader]]

(In reply to Pascal Chevrel:pascalc from comment #5)

Robert, do you intend to work on this bug or should we find an owner?

I'm afraid I won't find time ATM, so finding an owner would be good indeed.

Comment 7

[Pascal Chevrel:pascalc (PTO until April 26)]

Martin do you think that this should block our meta bug for Wayland general availability? (bug 1752398)

Comment 8

[Martin Stránský [:stransky] (ni? me)]

Sure, why not.

Comment 9

[Martin Stránský [:stransky] (ni? me)]

Tested on latest nightly but I'm unable to reproduce. Also Dark Space doesn't work for me (at least I don't see anything animated) so I'm using sakura theme for testing (https://addons.mozilla.org/en-US/firefox/addon/animated-sakura-by-candelora/).

Kestrel, can you please check again with latest nightly?
Thanks.

Comment 10

[Kestrel]

I can't reproduce it with ANIMATED Sakura either, perhaps because of the image format (png, 2.2MB, ~1 second). I can still reproduce it on latest Nightly 107.0a1 (2022-10-10) with Dark space (gif, 2.7MB, ~8 seconds) and The Generator (GIF) (gif, 5.9MB, ~7 seconds).

Comment 11

[Martin Stránský [:stransky] (ni? me)]

Thanks, will check the Generator theme.

Comment 12

[Martin Stránský [:stransky] (ni? me)]

It's because we fail to recycle decoded images but we keep to create a new ones. I wonder if that's related to two vsync/refresh drivers running together while one doesn't fire VSync events as it's hidden.

Comment 13

[Martin Stránský [:stransky] (ni? me)]

To fix this one we need to fire some vsync events even when the window is hidden. AFAIK refresh driver fires two ticks per second for hidden windows. We may also fire OcclusionStateChanged() if window is hidden for long time.

Comment 14

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1786247 [Wayland] Print nsWindow as part of Vsync logs r?rmader

Comment 15

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1786247 [Wayland] Add Vsync idle callback r?rmader

Depends on D159037

Comment 16

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1786247 [Wayland] Implement Vsync idle callback and fire reduced vsync events if nsWindow is hidden r?rmader

Depends on D159038

Comment 17

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1786247 [Wayland] Use layout.throttled_frame_rate to set idle frame rate r?rmader

Depends on D159039

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/94ddd239c0d6
[Wayland] Print nsWindow as part of Vsync logs r=rmader
https://hg.mozilla.org/integration/autoland/rev/87e8a37d1e93
[Wayland] Add Vsync idle callback r=rmader
https://hg.mozilla.org/integration/autoland/rev/f063a768cbf1
[Wayland] Implement Vsync idle callback and fire reduced vsync events if nsWindow is hidden r=rmader
https://hg.mozilla.org/integration/autoland/rev/6b355532cd2d
[Wayland] Use layout.throttled_frame_rate to set idle frame rate r=rmader

Comment 19

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/94ddd239c0d6
https://hg.mozilla.org/mozilla-central/rev/87e8a37d1e93
https://hg.mozilla.org/mozilla-central/rev/f063a768cbf1
https://hg.mozilla.org/mozilla-central/rev/6b355532cd2d

Comment 20

[Daniel Bodea [:danibodea]]

I have managed to reproduce this issue on Release v106.0.1 launched with wayland Window Protocol on gnome desktop environment.
I've done so by installing the Dark Space theme mentioned originally and opening 2 windows where one visually covers the other. By watching the Memory and Swap section of the System Monitor I can observe that the memory rises slowly until the hidden window is brought into focus, then the memory drops back to the base level.

The fix confirmation was attempted on Beta v107.0b4 and Nightly v108.0a1, but it appears to still reproduce in the same manner.

Martin, is the method I'm using a valid method?

Comment 21

[Martin Stránský [:stransky] (ni? me)]

(In reply to Bodea Daniel [:danibodea] from comment #20)

I have managed to reproduce this issue on Release v106.0.1 launched with wayland Window Protocol on gnome desktop environment.
I've done so by installing the Dark Space theme mentioned originally and opening 2 windows where one visually covers the other. By watching the Memory and Swap section of the System Monitor I can observe that the memory rises slowly until the hidden window is brought into focus, then the memory drops back to the base level.

The fix confirmation was attempted on Beta v107.0b4 and Nightly v108.0a1, but it appears to still reproduce in the same manner.

Martin, is the method I'm using a valid method?

Please file a new bug for it and attach about:memory reports. Also please attach about:support page.
Thanks.

Comment 22

[Kestrel]

I can still reproduce this leak in latest Nightly 108.0a1 (2022-10-25) on Ubuntu 22.04, the memory report is the same as before:

4,126.39 MB (100.0%) -- gfx
└──4,126.39 MB (100.0%) -- webrender
   ├──2,219.32 MB (53.78%) -- textures
   │  ├──1,912.55 MB (46.35%) ── render-texture-hosts
   │  ├────128.00 MB (03.10%) ── render-targets
   │  ├────118.50 MB (02.87%) -- texture-cache
   │  │    ├──118.50 MB (02.87%) ── atlas
   │  │    └────0.00 MB (00.00%) ── standalone
   │  └─────60.27 MB (01.46%) ++ (7 tiny)
   └──1,907.06 MB (46.22%) -- images/mapped_from_owner
      ├──1,902.16 MB (46.10%) -- pid=19542
      │  ├──1,892.29 MB (45.86%) ── image(640x360, compositor_ref:3, creator_ref:1)/decoded-other [2153]
      │  └──────9.87 MB (00.24%) ++ (24 tiny)
      └──────4.91 MB (00.12%) ++ (2 tiny)

It initially seemed to be fixed until Bug 1795574 was corrected.

Comment 23

[Robert Mader [:rmader]]

Oh, that could be because https://searchfox.org/mozilla-central/source/widget/gtk/WaylandVsyncSource.cpp#281-296 - after bug 1795574 we now unconditionally set the occlusion state to visible again. Emilio, can you have another look?

Comment 24

[Martin Stránský [:stransky] (ni? me)]

(In reply to Robert Mader [:rmader] from comment #23)

Oh, that could be because https://searchfox.org/mozilla-central/source/widget/gtk/WaylandVsyncSource.cpp#281-296 - after bug 1795574 we now unconditionally set the occlusion state to visible again. Emilio, can you have another look?

That change should be correct - if we get frame callback from wl_surface it means the surface is visible. This is not related to Vsync - we just use one source (frame callback) for two independent purposes.

The core fix here is that we fire VSync event even when we don't get frame callback. That allows gecko to release unused resources (cached decoded images in this case) so we don't need to allocate new ones but uses image recycling. I wonder if we hit a different bug or the Vsync does not free the cached images.

Comment 25

[Emilio Cobos Álvarez (:emilio)]

Yeah I don't think that is to blame... The occlusion code seems to work locally, fwiw...

Comment 26

[Kestrel]

The regression range includes some relevant Webrender changes and the bug does not occur with the Basic compositor. I will file a separate bug in the Webrender component.