GNOME Bugzilla – Bug 746494
orca lags quite badly when navigating lists with many items
Last modified: 2015-08-06 22:49:23 UTC
When navigating any application with lots of items on screen, whether this be an icon view, list, table or tree view, orca lags if the number exceeds more than a few hundred. I have two debug logs form two different systems, one a laptop, very slow, and one from my main desktop system. Both attempted to do two things. Navigate a folder with lots of items in it in nautilus, and then navigate accerciser's api browser treeview. Logs are attached
Created attachment 299897 [details] debug file from my desktop describing the orca lag in multihundred item lists, tables, etc in this file I've done two things. navigated a folder in nautilus containing several hundred items, and navigated accerciser's api browser page
Created attachment 299898 [details] debug file on mellisa's laptop describing the orca lag when navigating multithousand item lists In this debug file I tried navigating the \windows\system32 folder, which has several thousand items in it, and navigated accerciser's api browser page. I also searched for a few things in gnome shell to demonstrate the unpredictable reading of the initial result.
Created attachment 300010 [details] this is a debug file from seamonkey. Attempting to invoke a list of any element on a page when there are quite a few (this one had over a thousand) causes the same significant delay. I had to compress
If accerciser is running at the same time Orca is, bad things can happen because both are listening for and processing accessibility events. And when accerciser responds to some, it causes additional events which Orca must process. It would be extremely helpful to have a debug.out in which you illustrate with one or two keypresses only the problem -- and do so without accerciser running. That way I can focus on the debug.out output that's relevant. I don't need them from both machines either. Just one from yours will hopefully suffice. Thanks!
Created attachment 300154 [details] debug file describing orca's lag in long lists. I went into /usr/bin which has something like 2800 files in it.
It looks like the problem is in calculating the position in list (item x of y). I'll see what I can do to optimize that, but in the meantime could you please confirm that if you disable that option the log goes away?
I've just disabled both "speak object nemomics" and "speak child position" in orca's preferences. It seems to help quite a bit, though there is an initial lag of several seconds when entering a list with multiple hundreds or in this case thousands of items before the first icon is spoken. After this, it's much snappier. Could be an event flood, I'm not sure.
Could you please get me a debug.out with all of those things disabled so I can look at a lag to see if it's a flood? I found one event flood from Gtk+ from a different bug filed against Orca. See bug 746706. I don't *think* that particular issue is what you're seeing here. But it could be that what you're seeing is something similar. If so, I want to hunt it down and see if we can get it fixed in the toolkit(s).
Created attachment 300227 [details] Debug file with "speak object nemonics" and "speak chile position" disabled. SOrry for teh short message, being rushed to go shopping
Kendell, ignoring the 3000+ combo box issue (which I explained on the mailing list), is this bug fixed for you in master?
I'm not sure it's completely fixed, but in my test case, a nautilus folder with many many items, it's definitely a lot more performant. I'll leave it open for now only because I need to find a list with thousands and thousands of items in it that's not the varients combo box in preferences. If I find one and it's as good as nautilus, I'll closed as fixed. It's a lot better than it was before, great work!
This bug seems fixed, so far as I can tell. I've gone in search of large lists, icon containers, etc. The largest I could find was opening up /usr/bin in nautilus, which has 3700 items in it. It took a few seconds to load the folder, which I suspect is nautilus, but after that orca was instantaneously responsive. Marking as fixed (resolved)