GNOME Bugzilla – Bug 547880
[blocked] Long delay when starting nautilus, navigating in gconf-editor, and generally accessing large lists/tree views.
Last modified: 2013-01-02 15:43:06 UTC
Hi, There is a very long delay when starting nautilus in a folder of ~500 files. On my machine, it takes about 20 seconds. The reason is - as far as I can tell - that orca is flooded with object:state-changed:showing events: vvvvv PROCESS OBJECT EVENT object:state-changed:showing vvvvv OBJECT EVENT: object:state-changed:showing detail=(0,0) ^^^^^ PROCESS OBJECT EVENT object:state-changed:showing ^^^^^ Which apperas aproximately 1500 times. Does the detail (0,0) mean, that it changes from false to false, or am I misunderstanding something? :-) I don't think, that these events are used for anything in this case - at least, I didn't find anything when looking for ":showing" in default.py, focus_tracking_presenter.py and scripts/apps/nautilus.py. Is there a way to find out, to what object these events refer (setting event_debug_level to info didn't work)? I suspect, that these events occur one for each table cell... Is there a posibility to filter these events out before too much time is lost on them? Thanis in advance, Regards, Rudolf
Nautilus itself is pretty slow to open folders with lots of items, regardless of whether Orca is used or not. It would be nice to try to prevent the object:state-changed:showing events from being delivered if we could. The problem is that we need to listen for them to handle tooltips and to handle odd situations such as the screen saver dialog. We *might* be able to try to selectively turn on/off listening for these events if we can detect certain situations, but I'm not sure of a graceful way. Another thing might be to see if there is something that can be done in nautilus itself to be a bit more performant and to rework code so as to prevent this flood of events.
I suspect this depends upon bug #577098, so I'm adding it as a dependency.
Modifying the summary to reflect the broader problem so that we do not need to keep multiple Orca bugs open to track a single issue over which we have little to no control.
Bulk reassigning Will's bugs to the default assignee. (Sorry for the spam!)
This is an old bug. Much performance work has been done in general (Orca, a11y libs, Gtk+), and with Gtk+ treeviews in particular. So I'm closing this out as OBSOLETE.