Reduce RAM Memory Usage

[CaptainMorgan12]

Describe the bug

Environment: furios trixie, tuba 0.9.2 flatpak install.

It varies but typically Tuba uses 100-500MB of ram depending on time app has been running or how far back you go in feed. That is more than firefox on mobile on my phone.

For memory constrained devices it would be good to limit ram usage more.

Steps To Reproduce

1. Scroll back in time on feed
2. select 10 -20 posts per load batch
3. select 1-2 external links opening firefox
4. 24hrs = ~ 650MB
5. 48hrs =~ 716MB
6. at which point it doesnt let you scroll back further in time in the feed

RAM correlates to posts loaded, number of users you follow and hence # posts per day, and one solution maybe to reduce resolution of images in feed during loading, not prefetch linked content (if it does that?), trim memory similar to firefox when app is in background (not being used)

Logs and/or Screenshots

<paste your logs here>

Instance Backend

social.librem.one

Operating System

furios trixie

Package

Flatpak

Troubleshooting information

No response

Additional Context

No response

[GeopJr]

It's related to #1301 #1314 #504 #500 #179 and anything else with the word 'listview' in it

TLDR: the way timelines work at the moment is with ListBoxes. Everything in the listbox stays in memory until cleared (refresh, close the timeline). ListViews on the other hand are recyclers, they make a handful of widgets and recycle them as you scroll; that way ram usage stays pretty consistent. But 1. this requires major rewrites as its both a lot more limiting than ListBoxes and works nothing alike and 2. it has some issues, for a long time when I did introduce it in one of the linked PRs, it wasn't keyboard navigateable at all. That was fixed in later GTK versions, but another big issue is the way the recycler calculates the height of the ListView when there are widgets with inconsistent height (aka all posts) can cause it to constantly be stuck in recycling the edge widgets which looks like the view is going up and down rapidly.

I'll close this as it doesn't really point out anything the other issues don't (and it's a bit too generic to act upon). The only things I can say are:

1. I'm very aware of and frustrated with it too
2. I'm planning to focus 100% on performance and optimizations after the next release (unless fedi software decide to drop 1000 features in one go that I'll have to support)

[CaptainMorgan12]

thank you for the details, i didnt realize it was all due to the listview implementation, your efforts are much appreciated.

[GeopJr]

I think there are other places we can optimize but yeah... as an issue is a bit too generic like 'fix bugs'.

In general however, ListView is the big one, quoting myself from #1301

Anyway, ListView is the 1.0.0 blocker. This is yet another retry. Memory wise, it works. No matter how many posts you scroll down it will always be < 200 MB.

But that's because it patches GTK to limit it to 20 items recycler. We need to make our own one.