GNOME Bugzilla – Bug 76082
funny lag in background toggle buttons
Last modified: 2004-12-22 21:47:04 UTC
When you choose one of the toggles, it lags for a second with both the old and new toggle selected, then goes to the new one. Should not work that way, should go ahead and immediately go to the new one (without waiting for the gconf notify to come back, if that's the issue).
The capplet checked into CVS is a rewrite by Richard, I don't really know how it works now.
Would be nice to have fixed but not exactly a big deal.
Updating all cc bugs that have the GNOME2 keyword set to the GNOME2.0 milestone, to help jrb triage/prioritize cc bugs. Filter on 'luis doing GNOME2 work' to ignore this spam.
Enclosed you will find a patch to fix this. Havoc: let me know if you like the fix, I am concerned about it creating a race condition, we should have a fix like this in a lot of places of gnome. Who cares about speed ? when it is all about the PERCEIVED speed. One thing that we could do is process only the drawing & signal events and ignore the keyboard & mouse ones. We could have this in a 1,000 other places in GNOME, it is amazing how much faster things seems when you do this. This is in gconf-property-editors, which i would love to see inside gconf, so it is really your call if this code is going to be yours eventually. But even if you don't like the fix, try it out to get a sense of what big of a difference this makes. If you like the fix, i can do it for all of the property editors (or find a gnome-lover to do it). Chema
Created attachment 9340 [details] [review] patch
Yeah, it looks like that could easily create reentrancy problems leading to segfaults and such. Is the problem really lack of redraw before a gconf_client_set()? gnome-terminal prefs also does gconf_client_set() before redraw, and there's no visible lag in that case...
Yes, it is the lack of redraw which you can see by using this patch. I think the difference with gnome-terminal is that we have pixmap buttons which we need to set the "shading" again, it is just consuming the cpu which is sharing with the gconf notification and signal back. So yes, this patch could create a problem but i'd love to find a general solution to do this hack of "draw right now all pending events", i've done it before inside gnumeric and the perception of speed improvement is huge, jody didn't took the patch for the same reason, but i think the general idea of beeing able to trow "drawing points" is sexy and well worth it, we just need to find a safe way of doing it. In gnumeric what was happening is that the menu selected would cover part of the spreadsheet, when you opened a dialog glade would start parsing the xml and creating the widgets, however the menu was gone but the area of spreadsheet covered by the menu didn't got redrwan only after the glade file was done loading and the dialog was created. By just adding this same hack the perception of speed improved dramaticaly.
SPAM as discussed last night. Search for 'SPAM as discussed last night' to catch these all and delete them. :)
Works in GNOME 2.2