Repository navigation
Slow/delayed switching between active/inactive state with certain Gtk+ themes #204
Description
I've been experiencing this really odd bug where switching to and from Cawbird as the active window is slow/delayed - but only with certain Gtk+ themes. I can't find any rhyme or reason as to why only certain themes cause this behaviour. All other applications do not exhibit this behaviour. The best way to show it is a video so... I made one. With my phone, since I wasn't sure a screenrecording would actually capture it.
The theme I'm currently using is this one, and a theme I know for sure that doesn't have this issue is any of the many available Arc themes. The issue has been there forever as far I can remember, and while not a major bug, it is annoying as it also seems to cause the app to stutter a bit when switching to it.
This is on Linux Mint 20, Cinnamon, fully updated, running Cawbird 1.2.1. I think it may perhaps be related to a combination of Cinnamon's Mutter fork (Muffin) and Cawbird using CSD, but that's just a wild guess. Other CSD apps do NOT have this bug.
Activity
IBBoard commentedon Oct 30, 2020
Is there a short (<1s) delay between you clicking to it and everything repainting?
I'm not sure how we debug this. I don't know of anything special that we do that might cause it. And I don't know how you'd debug something that's basically all GTK. I'll have to check some of the logging options.
thomholwerda commentedon Oct 30, 2020
As you can hopefully see in the video, it doesn't seem it's a full redraw - it's the switch from the theme variant for inactive windows to the active one (and vice versa). To replicate, open e.g. a basic Gtk+ app (like Gedit or Xed) and Cawbird (with one of the offending themes set), switch between the two windows.
It could be some difference between how each theme is coded, but that still doesn't explain why only (as far as I can tell) Cawbird is affected. I've been trying to find another app that exhibits the issue, but no luck so far. I'm not a programmer, so this might be a dumb question, but perhaps Cawbird uses a rare Gtk+ element some themes stumble over?
Let me know if you need me to run a debug build or whatever, or anything else I can do to help!
IBBoard commentedon Oct 31, 2020
It looks like I get it here as well, and just never noticed. I'm using a modified version of Adwaita, so it shouldn't have much affect other than having been loaded from CSS files in my home directory.
Oddly, if I bring up the Settings dialog then it is slow to swap between the main window and the Settings (or between the main window and another app) but quick between the Settings dialog and the other app. Which at least narrows it down to "probably the timeline widgets".
IBBoard commentedon Oct 31, 2020
Well, it definitely appears to be
TweetListItemrelated (i.e. the timeline). If I remove the Twitter API calls that make us populate the timelines then everything is quick and responsive.It's not an image problem - if I disable image loading then it still has the lag.
It's not the fact that we've got scrollwindows inside scrollwindows (to stop tweets with very long unbreakable words stretching the whole window) - if I swap that out for a Bin then it's still slow.
If I add logging in to the
get_preferred_height_for_widthandsize_allocatefunctions then it appears to do a lot of requesting new sizes for each widget, but as I understand it then that's just normal GTK behaviour. And we shouldn't do anything particularly expensive most of the time.Anyone know how to debug GTK's repainting process? 🙂
thomholwerda commentedon Oct 31, 2020
Could it be an idea to file a Gtk+ bug? If this is out of your control, that seems like the right thing to do.
IBBoard commentedon Oct 31, 2020
I want to rule out that we're not doing something odd that makes it self-inflicted first. There's nothing more annoying for libraries than getting bug reports that are just "I didn't use the API right". I'd probably go to the Gnome forums first.
IBBoard commentedon Oct 31, 2020
More debugging: Even if we only have
HomeTimelineavailable (remove the rest from the list inMainWidget) then it has the lag. And that's with ~40 items loaded.[Update]
More debugging:
TweetListEntryis just the tweet text then it is faststack(so there's no actions or "sensitive" message to swap to) then it lagsStarting to wonder whether it's the grid!
thomholwerda commentedon Oct 31, 2020
I don't have much useful stuff to add at this point, only to say that I am always surprised when something so small can lead to such a bug hunt :D.
IBBoard commentedon Nov 1, 2020
I think that's called "software development" 😉
IBBoard commentedon Nov 3, 2020
More debugging:
HomeTimelinethen it's reasonably quick but not perfectHomeTimelinethen it's not showing as much lag as I saw previouslyI'm starting to think that there's a problem between the "custom widget per tweet in a list" code and the way the UI handles the multiple views. I wonder whether @CodedOre is seeing any similar behaviour with #177 and the redesign?
CodedOre commentedon Nov 3, 2020
I am not at that point to redesign the Tweet design in my libhandy-port (also took a break from working on that last week).
So, can't really give an experience here.
However, I have worked with an similar thing while reworking the AboutDialog (as I made a custom adaptive one, don't really know why).
I also had there a Grid which would basically be a list in adaptive view.
What I have done was to keep the grid, but to remove the elements from the grid and readd them in different positions when the change is done.
For one grid, it did worked well, but I can't say how the performance of that method would be when used to display the tweet.
IBBoard commentedon Nov 3, 2020
I think this is separate from the 'responsive' design issue and moving widgets. And I only rearrange the grid if/when we cross the "responsive threshold", otherwise it just calls standard GTK code. I'd always assumed that removing and re-adding items would be slower than just adjusting a few attachment values, though!
I just grabbed a copy of your repo and tested out the main (only!) branch. It looks like you've still got the same issue, but then you're still using the same
MainWidgetwith all the views, so it makes sense.CodedOre commentedon Nov 3, 2020
Well, like mentioned, I only implemented a similar system in the AboutDialog.
I currently looking trough the backend code to what and how I need to change it (as I need a few additional functionality for displaying a thread in the future), so I did not went to implementing more of the new UI yet.
36 remaining items
Re #204: Fix self-transitions
Re #204: Workaround a "jump to top" bug
Re #204: Grab focus with RT button on repeat
IBBoard commentedon Mar 11, 2021
I've been running with this as a custom patch for a little while and I've not noticed any problems, so I'll merge it.
Re #204: Remove stack for showing tweet actions
Re #204: Hide stack widgets we aren't showing
Re #204: Work around "don't know height on resize"
Re #204: Add and remove pages when navigating
Re #204: Fix self-transitions
Re #204: Workaround a "jump to top" bug
Re #204: Grab focus with RT button on repeat
IBBoard commentedon Mar 11, 2021
Fixed by #335
ValdikSS commentedon Jun 19, 2022
@IBBoard, unfortunately I can't say this is fixed for me in 1.5.
It may be worse earlier, but with GTK3 HighContrast theme, it redraws the window at 4 fps when it is focused or unfocused.
The issue is "backdrop" effect. Everything is very smooth with "Clearlooks-Phenix" theme which does not have it.
cawbird-2022-06-19_05.36.36.mp4
IBBoard commentedon Jun 19, 2022
There's not really much more that we can do. We don't add backdrop effects, they're part of the system theme. We've already stripped back the unnecessary widgets (pages are removed when they're not the focussed one). I can't think of any other changes that we can make.
GTK4 apparently has better handling of lists of lots of widgets, so it will have to be something that is resolved with the redesign.