Slow active/inactive state change

Platform
,
1

One of my users has reported that my GTK3 app is slow to transition between “active” and “inactive” states. They’ve provided a video:

https://photos.google.com/share/AF1QipMfmBcZuH_HgaAfi1cfFd33nUunBPU4AiI65lgmFn0gW-zmCYOjfStudDw1E-Hr_g/photo/AF1QipNjqPb0-G4IyH9iD8EIbnixu1qa5tWYpyNXTO3b?key=YXZwZkdKWjFGWFF4bm10ODR4ZlBYYUN0MzRRbjV3

The delay is between the window getting focus and the window rendering in the “active” styling. You can click on the window, it’ll come to the front, there will be a short but noticeable delay, and then it’ll render as “active”. This happens with all themes, including Adwaita, so it’s not just the user’s theme causing it. It doesn’t happen when you’ve got a dialog (e.g. Settings) open.

The main window is a set of GtkListBox widgets containing custom GtkListItems that contain a GtkGrid with text and some image widgets.

If I limit it to 1 item in the list then the lag isn’t noticeable, but I wouldn’t expect 25 items (the default amount) to cause an obvious lag. It doesn’t appear to be the media, because the lag still happens when they’re not included.

What can cause the lag? How can I debug it? Is it just an unavoidable part of having lists with custom widgets in? From the logging I’ve added so far, it doesn’t appear to be a cascade of reallocations or anything, and I can’t find a way to debug CSS rendering.

Thanks.

2

It’s likely caused by the backdrop state invalidating a lot of UI elements; see, for instance: Add possibility to disable backdrop (#777) · Issues · GNOME / gtk · GitLab

The backdrop state has been toned down in GTK4, but I’m not sure the changes have been backported to GTK3, yet.

Large numbers of widgets invalidating their CSS state cause rendering to slow down.

There’s not much that can be done, outside of changing the theme to remove a lot of the backdrop state changes.

3

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.