GNOME Bugzilla – Bug 646019
best-match app has its selection highlight redrawn on every keypress
Last modified: 2011-04-15 17:35:09 UTC
If the best-match app doesn't change because of the new keypress, its selection highlight shouldn't be redrawn, to avoid it flickering.
Created attachment 185489 [details] [review] Select the item before its rendered to avoid the flicker/redraw
Comment on attachment 185489 [details] [review] Select the item before its rendered to avoid the flicker/redraw Ok, realizing this isn't a good patch - doesn't set the _selectedProvider or selectedIndex properly.
Created attachment 185491 [details] [review] Updated patch which doesn't regress Enter-activates behavior
(In reply to comment #3) > Created an attachment (id=185491) [details] [review] > Updated patch which doesn't regress Enter-activates behavior The patch works, but the approach of propagating the initial selection is a bit ugly ... I'll propose an alternative approach which should work equally well, while being simpler and less intrusive.
Created attachment 185531 [details] [review] search-results: Fix flickering of the selection When updating search results, the current result set is recreated from scratch before setting the selection highlight. This results in two style changes of the selected item (the first one when mapped, the second one when setting the selection), which causes flickering if the selected item remains the same as with the previous search term. Fix by hiding the result set until the selection is set, so that the style of each item changes only once when mapped.
I basically don't understand why there is a return to the main loop that would allow painting in the unselected state - it doesn't matter what order we do things as long as we don't do some stuff, return to the main loop, then do some more stuff.
Review of attachment 185531 [details] [review]: I think the code here is fine, but the comment and commit message are pretty unclear - the fact that hiding unmapping actors prevents triggering a CSS transition is completely unobvious.
(In reply to comment #6) > I basically don't understand why there is a return to the main loop that would > allow painting in the unselected state - it doesn't matter what order we do > things as long as we don't do some stuff, return to the main loop, then do some > more stuff. As mentioned on IRC, the problem here is that we do a transition from unselected->selected, and we are not smart enough to determine that the unselected style hasn't been actually painted. (So presumably the remaining patch in bug 627083 would fix the problem as well).
(In reply to comment #7) > Review of attachment 185531 [details] [review]: > > I think the code here is fine, but the comment and commit message are pretty > unclear - the fact that hiding unmapping actors prevents triggering a CSS > transition is completely unobvious. Yeah, my bad - I only investigated the actual reason today :(
Created attachment 185915 [details] [review] search-results: Fix flickering of the selection Updated comment and commit message.
Review of attachment 185915 [details] [review]: Looks good
Attachment 185915 [details] pushed as f0622c1 - search-results: Fix flickering of the selection