Widgets never get released and destroyed
Description
I've been noticing slowdowns over time with heavy use of certain widgets. A closer inspection seems to indicate that a sizable portion of widgets never get released and destroyed. Which in turn also carries a ton of signals and bindings being active at all times, while no longer being relevant or useful.
Also memory increases over time with widgets never getting destroyed.
Specifically the chain of ArtistAlbumsWidget
-> AlbumWidget
-> DiscBox
-> SongWidget
is kept alive indefinitely it seems.
Steps To Reproduce
- Add a print statement in
CoreSong
's selected property (with the song name) to see how often it gets triggered over time. - Go to the
ArtistsView
, switch between 2 artists for a while. - Notice the increase in how often a single songs 'selected' property gets checked over time. This indicates the widgets bindings stay alive and active.
- You can also attach a
weak_ref
to aSongWidget
on creation, the callback never gets called on these widgets.
Expected Behaviour
The widgets to be destroyed and all the bindings in the process, not resulting in ballooning and slowdown because of way too much property triggers.
Actual Behaviour
- Slow burn.
- Memory ballooning.
Specifications
Gnome Music Version: Tested on 44
Desktop Environment: GNOME
Wayland or Xorg: Wayland
Flatpak or Native: Native (I expect Flatpak to be the same)
Tracker Version: 3.5.3
Grilo Version: 0.3.16
Additional Information
I tested this in the live environment, but it is too difficult to track down the issue. This needs a small reproducer to get a real idea of where to look and I suspect it might be in PyGObject
or maybe some circular logic between all the signals and bindings Music has.
The way this works is that we use GtkListBox
with bind_model
often to work with our ListModel
's, when setting a new model the old model's widgets should get destroyed. The ListBoxRow
's do get destroyed, but the child widgets do not.