GNOME Bugzilla – Bug 778158
Performance of focus_chain in a common scenario
Last modified: 2017-02-09 02:54:09 UTC
If we want to implement a navigation in our own way, the preferable way will be use the get_focus_chain of St.Widget, to implement our own navigation mechanism. In a big set of items use the current implementation of this is slow, as st_widget_real_get_focus_chain is implemented in this way: https://github.com/GNOME/gnome-shell/blob/master/src/st/st-widget.c#L822 It's not filter by (CLUTTER_ACTOR_IS_VISIBLE (child)) and this is a big difference in performance, as we sure have several invisible actors, where we don't want to iterate. The performance issue was introduced in this commit: https://mail.gnome.org/archives/commits-list/2012-February/msg04234.html There are a way that will be possible, provide another function to compute only the visible actors from the c side? Make it in gjs, it's really slow.
Created attachment 345144 [details] [review] widget: Only include visible actors in focus chain It isn't useful to move the keyboard focus to a hidden actor, so only include visible actors in the focus chain - this is in fact the documented behavior of st_widget_get_focus_chain(), so having the default implementation return all children has always been unexpected. (In reply to Lester Carballo from comment #0) > There are a way that will be possible, provide another function to compute > only the visible actors from the c side? I don't think a second function makes sense here - after all, navigate_focus() would still use the first one. We can just adjust get_focus_chain() itself so that it matches the documented behavior ...
I just thinking this was intentional to be used in some places. Of course the second function it's not needed now... So, thanks. I'm try to get back the Cinnamon gjs code to gnome shell. Most of things are working more faster in gnome shell that in cinnamon, just not the menu: https://github.com/lestcape/Classic-Gnome/commit/969c46492840efd035fdb46c431ea13332b1af6a Thanks again.
Review of attachment 345144 [details] [review]: indeed
Attachment 345144 [details] pushed as a870a4d - widget: Only include visible actors in focus chain
What actually could have scene it's get the next focuses actor without a real move of the focus. In some context, you want to cause the impression of a focus change, but not move the focus it's self... Example: You have the focus in an entry and you don't want to move the focus but, you want to change the selected item at the same time. st_widget_get_focus_chain, will now work faster in a commons scenarios and will resolved most of cases where the list of actors it's not extra-big... With an extra-big list, i think also the whole shell could notice the impact.
Something like: st_widget_next_navigation_focus(StWidget *widget, ClutterActor *from, GtkDirectionType direction) where the from ClutterActor, not need to have the focus to get the successor in the focus chain.