Does not necessarily react instantly to clicks that change the view

[stuartlangridge]

Describe the bug
Clicking one of the icons that switch between timelines (from the home to the mentions or DM or liked timelines, etc) will often not react at all for a second or two before switching. This makes cawbird feel sluggish, and a bit like a badly-implemented web app (avoidance of which is kinda the reason I'm using this native app :-))

Of course, it may take time to build the new timeline from widgets, and that's understandable. But cawbird does not have to wait until the timeline is fully constructed before reacting to the click. If the app reacts somehow to the click to change the timeline within 100ms then it will feel as though it reacts instantaneously; even if it then takes the other 900ms of the 1s to build the timeline visually, it will feel faster because the app didn't ignore the click for 1000ms first.

A very short video to demonstrate.

cawbird-slow.mp4

Perhaps doing the "slide in the next pane" instantly, and then populating it immediately afterwards, could be the thing to do here?

[IBBoard]

That's… weird. We had #204 which was about the "focussed"/"unfocussed" style being slow to apply and the answer was basically "yeah, it happens and there's nothing you can do".

I've never seen anything quite that slow. Here's what I see (admittedly on a Zen 3 Ryzen with 32GB RAM!) but I don't remember it being slow like that on my old 4th Gen Core i5.

Peek.2021-09-24.20-33.mp4

There might be things that we can do to populate the widget after the transition. But each tab keeps its model up-to-date as it polls for new tweets/DMs in the background (which is how it knows to show the "new content" dot), and #204 already made it so that we don't add the widget to the stack until we're ready to switch to it.

Have you tried it with the Adwaita theme? Could it be a themeing issue?

[stuartlangridge]

I've just tried with Adwaita, and it doesn't seem to make a difference. This is a little difficult to test, because cawbird gets slower as it uses more memory (and its memory usage does climb pretty high!) but even directly after starting, there's a perceptible delay between a click and the tab transition. (It's not as long as the above, which was taken after it'd been running for a while.)

[IBBoard]

I've just tried with Adwaita, and it doesn't seem to make a difference.

Okay, at least that rules one thing out. It means it's almost certainly the GTK CSS invalidation problem that we hit before, but in a different context.

This is a little difficult to test, because cawbird gets slower as it uses more memory (and its memory usage does climb pretty high!)

How bad is it? I've looked at memory usage before (#142) and put in some optimisations. There may still be things that aren't quite right because C is a horrible language that should never be used for userland apps, but we've got C code for legacy reasons and so we have to directly deal with memory management.

A few more details that might help:

• Which distro and version are you on?
• Which package of Cawbird are you using? Distro build, official OBS build, Flatpak, Snap, etc
• Which version of Cawbird are you running?
• How big is your scroll bar? Are there just a few tweets (Cawbird pruned it back down) or are there lots?

[Edit] Oh, and hardware specs might help as well.