GNOME Bugzilla – Bug 756312
Optimize backdrop state changes
Last modified: 2018-04-15 00:15:57 UTC
Created attachment 312972 [details] [review] patch See attached patch and commit message. This is something we added downstream at Endless for our app store and would be nice to upstream if possible.
Nope. I don't want random environment variables like that.
FWIW I wrote it this way because it's similar to GTK_OVERLAY_SCROLLING that already exists... I'm fine keeping this downstream only if it's not acceptable, but I am curious if you disagree with the implementation or the reason for this patch in the first place.
I don't feel great about the existing 'random' environment variables we have, and don't want to add more if I can help it. I disagree with the implementation as well though: Your commit message says: "...this is a lo-tech way for applications...". But environment variables are not for applications, they are for users. Ultimatively, if backdrop is too expensive for you, just use a theme that doesn't have it ?
Well adding the environment variable was much easier than adding a special API - and I am not sure that adding an API to disable backdrop would be a good idea. For what is worth, the theme already does not have backdrop selector; what's expensive is the invalidation of the whole widget tree, which will happen regardless of whether the theme supports backdrop or not.
(In reply to Cosimo Cecchi from comment #4) > > For what is worth, the theme already does not have backdrop selector; what's > expensive is the invalidation of the whole widget tree, which will happen > regardless of whether the theme supports backdrop or not. Now, that is something we can and should optimize away.... but that's of course not your deadline-friendly quick hack
From irc discussion, the way to optimize this would be to add GDK_CSS_CHANGE constants for STATE_BACKDROP as opposed to just STATE, and then maintain them properly.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new