GNOME Bugzilla – Bug 554688
navigation in gconf-editor doesn't work
Last modified: 2010-08-01 23:08:49 UTC
Please describe the problem: navigating in gconf-editor slows down the Desktop. Note this is not an accessibility Problem here. Maybe it has to do with large objects which orca needs to parse. Steps to reproduce: 1. type alt+f2 2. type gconf-editor 3. try to arrow down and read the conntens. Actual results: Expected results: Does this happen every time? Other information:
Is this possibly a duplicate of bug #353446?
I think the problem is the large information stored in large tables here. Maybe an core 4 quad has enough power for navigating in such tables. _this_is an performance problem I think.
Created attachment 122621 [details] debugging patch All this patch does is time and output how long it takes our call to table.getAccessibleAt to return. If everything is collapsed, it's around 0.25 seconds per call which ain't great. However, if cells are expanded, it starts at around 3.5 seconds. The fact that we call it several times just makes things that much worse. :-( This is the result of Down Arrowing from apps to desktop, both of which are collapsed: _getBrailleRegionsForTableCellRow - getAccessibleAt: 0.212798118591 _getSpeechForTableCellRow - getAccessibleAt: 0.23095202446 This is the result of pressing Shift Right Arrow to expand schemas: getChildNodes - getAccessibleAt: 3.63907694817 getChildNodes - getAccessibleAt: 4.04445981979 getChildNodes - getAccessibleAt: 3.58366990089 getChildNodes - getAccessibleAt: 3.73180317879 getChildNodes - getAccessibleAt: 4.04743504524 getChildNodes - getAccessibleAt: 0.261389017105 Dunno if this is an AT-SPI thing, a GTK thing, or something else....
I hacked at Atk, AT-SPI, and Gtk+/Gail this evening adding a new relationship: NODE_PARENT_OF. The change for each module is only a few lines. The new relationship is recognized by Orca. Performance differences (note that the number which follows "new way"/"old way" are the number of child nodes. The number after that is the time in seconds. The performance improvement is bloody huge. This should be fixed on the infrastructure side of things; not on the Orca side if things. =========================== new way 9 0.000730991363525 old way 9 23.5638701916 =========================== new way 2 0.000731945037842 old way 2 1.25174307823 =========================== new way 4 0.000732898712158 old way 4 0.757242918015 =========================== new way 1 0.000734090805054 old way 1 6.57471394539 =========================== new way 2 0.00074291229248 old way 2 5.74261903763 =========================== new way 1 0.000736951828003 old way 1 6.61324715614 =========================== new way 4 0.000734806060791 old way 1 7.058822155 =========================== new way 1 0.000760793685913 old way 1 38.6404290199
Created attachment 127382 [details] [review] possible solution (has debugging print statements) To see the performance improvement, you will need to get the latest Atk, AT-SPI, and Gtk+, apply the respective patches (see the bugs this bug now depends upon), and then apply this patch to Orca trunk. I've left the debugging statments in because there seem to be some occasions where the new relationship I created is not in place. I'll look into that more further. This also doesn't eliminate all slowness in the gconf-editor tree, but it seems to make one hell of an improvement. I'm not blocking this bug quite yet because I want to see what else is slowing us down as well as see why sometimes the relationship is not in place. All of this said, Will, whatcha think? It is presumably an API change, but it's a minor one I think. And a desperately needed one I think. Please let me know. Thanks!!
Created attachment 127383 [details] [review] possible solution (has debugging print statements) Added another timestamp debugging line just in case the first way fails. Sorry for the spam.
Nice! I say try to push this, though the Orca code should also include some defensive try/except checks in the event it runs into old AT-SPI code that doesn't have NODE_PARENT_OF. Nice work!
I am suffering this problem navigating in Thunderbird when I have a so big list of messages (about 2000 messages in my inbox). Before filing another bug I would like to be sure is not related to this one. I am using Orca trunk, and latest Thunderbird.
Created attachment 147293 [details] [review] proposed patch Now that at-spi, atk, and gtk+/gail from git master all have NODE_PARENT_OF, this patch causes Orca to check for this new relation and use it if found. It falls back on the old logic otherwise. And, as Will suggested, it's now in a try/except. I tried this with gconf-editor and it reduces the time it takes to Orca to present expanded nodes from 20+ seconds down to 3+ seconds on my machine. 3+ seconds is still not acceptable, but it sure beats 20+ seconds.... Anyhoo, I'll take a look to see where the 3 seconds is coming from. Will, please review. Thanks! (BTW, I didn't bother adding it to the Pidgin script yet because Pidgin doesn't use this relationship and I didn't see any point in checking for a relation which we know won't be present.)
Created attachment 147336 [details] dtrace output from one onActiveDescendantChanged FWIW, this is what occurs from start to finish once onActiveDescendantChanged has been called in gconf-editor. All I did was press Down Arrow to move from the collapsed 'apps' node to the collapsed 'desktop' node. Personally, I was surprised by the number of libgtk calls taking place. After all, presumably the libgtk events resulting from my pressing Down Arrow had already come and gone by this point. (Otherwise, how would we know that the active descendant had changed??).
Review of attachment 147293 [details] [review]: Looks awesome. Many thanks and please commit to master for 2.29.2.
Comment on attachment 147293 [details] [review] proposed patch Committed to master.
Will, do you have an opinion on this? > Created an attachment (id=147336) [details] > dtrace output from one onActiveDescendantChanged
(In reply to comment #10) > Created an attachment (id=147336) [details] > dtrace output from one onActiveDescendantChanged > > FWIW, this is what occurs from start to finish once onActiveDescendantChanged > has been called in gconf-editor. All I did was press Down Arrow to move from > the collapsed 'apps' node to the collapsed 'desktop' node. > > Personally, I was surprised by the number of libgtk calls taking place. After > all, presumably the libgtk events resulting from my pressing Down Arrow had > already come and gone by this point. (Otherwise, how would we know that the > active descendant had changed??). It looks like the libgtk calls are the result of updating the braille monitor.
Heheh. That didn't occur to me (obviously). Well, I just turned that off, and all debugging in Orca off, and while Orca's gotten more performant as a result, I'm still seeing the 3-second lag. I'll dig some more before closing this bug out. After sleep and brain cell regeneration. :-)
I'm *pretty sure* that the remaining lag is the result of: Bug 577098 - GtkTreeView (lists, Nautilus) is very slow with Assistive Technologies enabled (at-spi) We have a different blocking/tracking bug open for it, namely: Bug 547880 - Long delay when starting nautilus Therefore, I'm closing this bug out as FIXED because the outrageous delay we were seeing was solved by the addition and use of the NODE_PARENT_OF relationship. We can use bug 547880 to track the other GtkTreeView issue.