Slow/delayed switching between active/inactive state with certain Gtk+ themes #204
Comments
|
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. |
|
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! |
|
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". |
|
Well, it definitely appears to be 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 Anyone know how to debug GTK's repainting process? 🙂 |
|
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. |
|
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. |
|
More debugging: Even if we only have [Update] More debugging:
Starting to wonder whether it's the grid! |
|
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. |
|
I think that's called "software development" 😉 |
|
More debugging:
I'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? |
|
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). 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. |
|
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 |
|
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. |
|
Finally got round to asking on the Gnome forums - https://discourse.gnome.org/t/slow-active-inactive-state-change/5015 |
|
The official answer appears to be "we invalidate widgets; it happens". But I'm wondering whether Cawbird's current design keeps all of the lists active, even when they're not visible, and so maybe we're invalidating more than just the current page? Maybe libhandy will improve that? |
|
Reading linked tickets, this one suggests that The libhandy mockups show actions in the TweetList (which takes more space, but is more accessible) so hopefully it won't suffer from most of these issues. |
This mainly loses the cross-fade animation, but makes it feel snappier. We also have a minor bug where resizing while actions are visible can't track the grid height, but who activates actions on a tweet and *then* resizes the window? It all fixes itself after they toggle back to the tweet.
This improves app focus transition times but loses transition effects.
|
Those two commits seem to speed things up a bit BUT we lose the transitions. I don't think it's so important for actions, but I'm trying to keep the page transitions. I've got something half-working with each page being in a |
It isn't perfect because the views resize rather than moving and tweet to tweet doesn't currently transition, but it's something.
Part of the slow-down is because GTK invalidates and recalculates ALL of the widgets in the stack. But if we hide them then it doesn't need to do that. So when the transition ends, hide all widgets we're not showing. Currently seems to behave the same, but with faster focus switching.
If the actions can't know the right height as we resize then the only option is to stop showing the actions as we resize!
|
@thomholwerda Can you test the new branches? I was working on |
|
I was going to reply to my original Gnome post to reference the other bug from Baedert and point out that there's a possible work-around… but it got auto-locked yesterday! Hopefully people can still trip over this with Google. To (hopefully) increase the chances, here's my post text:
|
|
I've done a bit more testing. Entirely removing the stack is definitely faster, but the animations are… substandard. Hiding non-visible things seems to be faster, but I've not got numbers to confirm. |
Why inherit from a generic Widget when we can use an EventBox? This prevents potential problems where the media button windows don't align with the actual position in the window.
This is the harshest version of removing pages when we're not using them. We only keep extra pages in the stack until we're done with them. But the pages are still created and keep state, so they don't lose positions etc Also now pass the main window around so that we don't assume a base/parent when it might not be set. This won't work as-is with the libhandy redesign (because we need to keep all of the main tabs as children so we populate the switcher).
Part of the slow-down is because GTK invalidates and recalculates ALL of the widgets in the stack. But if we hide them then it doesn't need to do that. So when the transition ends, hide all widgets we're not showing. Currently seems to behave the same, but with faster focus switching.
If the actions can't know the right height as we resize then the only option is to stop showing the actions as we resize!
Why inherit from a generic Widget when we can use an EventBox? This prevents potential problems where the media button windows don't align with the actual position in the window.
This is the harshest version of removing pages when we're not using them. We only keep extra pages in the stack until we're done with them. But the pages are still created and keep state, so they don't lose positions etc Also now pass the main window around so that we don't assume a base/parent when it might not be set. This won't work as-is with the libhandy redesign (because we need to keep all of the main tabs as children so we populate the switcher).
Apparently GTK is "smart" and doesn't do the transitions if it doesn't need to. This means that it spots our "add the impostor, change to it, and then swap back" shuffle. BUT if we always had the impostor then it (silently) swaps to the impostor and then happily transitions.
|
I've just rebased the |
|
I think there's a bug in this. I've got a custom build that includes lots of new changes including this branch. When you right-click, it jumps to the top of the timeline. I presume something that I'm doing here is breaking the vadjust handling. |
Although we call `show()`, GTK hasn't *actually* shown it yet, so it can't grab focus. But it tries. Which kicks us to the top of the feed! We now `connect_after` on size allocation (which happens when the widget is shown) to wait until we're done.
|
Okay, now it should be okay for people to test. I might still put some small improvements in, though. |
Size allocate only happens once if the action box is shown, hidden and shown again, so we need to hook on to other events. Always pushing focus to the TweetListEntry and then moving it to the RT button when necessary seems to work.
This mainly loses the cross-fade animation, but makes it feel snappier. We also have a minor bug where resizing while actions are visible can't track the grid height, but who activates actions on a tweet and *then* resizes the window? It all fixes itself after they toggle back to the tweet.
Part of the slow-down is because GTK invalidates and recalculates ALL of the widgets in the stack. But if we hide them then it doesn't need to do that. So when the transition ends, hide all widgets we're not showing. Currently seems to behave the same, but with faster focus switching.
If the actions can't know the right height as we resize then the only option is to stop showing the actions as we resize!
This is the harshest version of removing pages when we're not using them. We only keep extra pages in the stack until we're done with them. But the pages are still created and keep state, so they don't lose positions etc Also now pass the main window around so that we don't assume a base/parent when it might not be set. This won't work as-is with the libhandy redesign (because we need to keep all of the main tabs as children so we populate the switcher).
Apparently GTK is "smart" and doesn't do the transitions if it doesn't need to. This means that it spots our "add the impostor, change to it, and then swap back" shuffle. BUT if we always had the impostor then it (silently) swaps to the impostor and then happily transitions.
Although we call `show()`, GTK hasn't *actually* shown it yet, so it can't grab focus. But it tries. Which kicks us to the top of the feed! We now `connect_after` on size allocation (which happens when the widget is shown) to wait until we're done.
Size allocate only happens once if the action box is shown, hidden and shown again, so we need to hook on to other events. Always pushing focus to the TweetListEntry and then moving it to the RT button when necessary seems to work.
|
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. |
This mainly loses the cross-fade animation, but makes it feel snappier. We also have a minor bug where resizing while actions are visible can't track the grid height, but who activates actions on a tweet and *then* resizes the window? It all fixes itself after they toggle back to the tweet.
Part of the slow-down is because GTK invalidates and recalculates ALL of the widgets in the stack. But if we hide them then it doesn't need to do that. So when the transition ends, hide all widgets we're not showing. Currently seems to behave the same, but with faster focus switching.
If the actions can't know the right height as we resize then the only option is to stop showing the actions as we resize!
This is the harshest version of removing pages when we're not using them. We only keep extra pages in the stack until we're done with them. But the pages are still created and keep state, so they don't lose positions etc Also now pass the main window around so that we don't assume a base/parent when it might not be set. This won't work as-is with the libhandy redesign (because we need to keep all of the main tabs as children so we populate the switcher).
Apparently GTK is "smart" and doesn't do the transitions if it doesn't need to. This means that it spots our "add the impostor, change to it, and then swap back" shuffle. BUT if we always had the impostor then it (silently) swaps to the impostor and then happily transitions.
Although we call `show()`, GTK hasn't *actually* shown it yet, so it can't grab focus. But it tries. Which kicks us to the top of the feed! We now `connect_after` on size allocation (which happens when the widget is shown) to wait until we're done.
Size allocate only happens once if the action box is shown, hidden and shown again, so we need to hook on to other events. Always pushing focus to the TweetListEntry and then moving it to the RT button when necessary seems to work.
|
Fixed by #335 |
|
@IBBoard, unfortunately I can't say this is fixed for me in 1.5. cawbird-2022-06-19_05.36.36.mp4 |
|
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. |
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.
The text was updated successfully, but these errors were encountered: