GNOME Bugzilla – Bug 650090
The at-spi2 cache forces creation of full accessible tree
Last modified: 2015-08-24 22:56:45 UTC
The current definition of the cache item includes its children's paths. It is a list of path, application path, parent path, interfaces, name, role, description and most importantly a list of child paths. In order to create the children paths it is often necessary to create the full object and in turn it's child objects. For a memory efficient implementation it should not be required to create the full tree of accessible objects. I would therefor propose to remove the list of child paths and include the number of children and the index in the parent instead. With this information the full tree for all included objects can still be reconstructed easily but not all objects have to be created. If a client is interested in an object, it can always request it by walking the normal child hierarchy.
I should have commented here a long time ago, when I pushed the code, but I have a patch to make this change in the cache-refactor branch of at-spi2-core and at-spi2-atk if we still want it. But then the QT bridge isn't implementing org.a11y.Atspi.Cache right now anyhow.
[Resetting QA Contact to newly introduced "at-spi-maint@gnome.bugs". Reason: So far it was impossible to watch changes in at-spi bug reports without following all the specific persons (Li Yuan, Bill Haneman, Jeff Wai, ...) and also their activity outside of at-spi reports. IMPORTANT: Anyone interested in following all bug activity (including all maintainers) must watch the "at-spi-maint@gnome.bugs" dummy user by adding it to the 'Users to watch' list under Preferences->Email preferences. This is also the default procedure nowadays in GNOME when setting up new products.]
[Mass-resetting default assignee, see bug 705890. Please reclaim this bug report by setting the assignee to yourself if you still plan to work on this. Thanks!]
This might have large impact on what has been reported against Mozilla Thunderbird here https://bugzilla.mozilla.org/show_bug.cgi?id=924915 Can this be please looked into and if the assumptions fixing this may improve the situation are in deed correct can the priority of this be increased please?
(In reply to comment #1) > I should have commented here a long time ago, when I pushed the code, but I > have a patch to make this change in the cache-refactor branch of > at-spi2-core and at-spi2-atk if we still want it. > > But then the QT bridge isn't implementing org.a11y.Atspi.Cache right now > anyhow. @Mike, Is this what will move the bug forward?
(In reply to Wayne Mery from comment #5) > (In reply to comment #1) > > I should have commented here a long time ago, when I pushed the code, but I > > have a patch to make this change in the cache-refactor branch of > > at-spi2-core and at-spi2-atk if we still want it. > > > > But then the QT bridge isn't implementing org.a11y.Atspi.Cache right now > > anyhow. > > @Mike, Is this what will move the bug forward? At the risk of being a noodge, what Wayne said. The Thunderbird problem still persists.
Created attachment 305632 [details] [review] Patch for at-spi2-core I've rebased the old patches (and possibly fixed a few things). I haven't committed yet, but I'm curious whether applying them will help.
Created attachment 305633 [details] [review] Patch for at-spi2-atk
Thanks Mike! Sorry for the delay in responding. Was at a hackfest all last week. I want to set up a jhbuild environment to test these. Started that just now and will hopefully have an answer for you tonight or tomorrow. Wanted to acknowledge these in the meantime (and say thank you).
Couldn't get a fully functioning jhbuild environment set up, so I wound up getting the source packages for my distro, applying your patches, then creating and installing new packages from that. So far I'm not noticing any differences: I've seen the tbird problem with and without the change. And I've seen it not happen with and without the change. But I'll take a fresh look tomorrow and if nothing else add some debugging output just to prove to myself I'm using the patched version when I think I am. :)
I would appreciate any change that may improve the Thunderbird accessibility situation that has been discussed here and on the corresponding Mozilla bug. So I've decided to test this my-self. Currently I'm running Arch linux with Gnome 3.16 including at-spi2-core and at-spi2-atk 3.16 patched with the patches attached here. Unfortunatelly the Thunderbird is still lagging verry badly with this configuration running. So far I've also discovered something it originally feels as a regression while running this. When trying to save an attachment contained inside an email message displayed in thunderbird, the file with the same name already exists Thunderbird shows a warning dialog. As that dialog appears orca freezes and has to be restarted. However putting Thunderbird aside this patch appears to be a complete game changer at least from my user's point of view. Gnome apps responsiveness increased dramatically. For example I can now comfortably browse large folders in nautilus. I've tried folders with about 700 items even single folder with more than 1600 items including subfolders. CPU increase while such a view is loading is no longer noticeable here, with orca running I can instantly navigate such large lists of files, navigation in such a list is snappier than ever before. I can keep holding one of the arrow keys down and I haven't managed orca to crash, to freeze or even started to lag. Without this patch applied the navigation within gnome apps is not as responsive as I am trying to explain here.
Mike: I'm afraid I haven't had time to dig into this wrt Thunderbird yet. But given what Peter reports, I'm wondering if you think this is safe enough to commit? We need all the responsiveness we can get.
I apologize for double postings but I have discovered some more situations where impact of these patches on general performance is more evident. For example open gnome-logs application, select all messages category and scroll down infinitelly. Well at least I have scrolled long enough so the list contained more than 1500 entries. Browsing this list even using other parts of the gnome-logs app did not introduce visible lags or performance issues. Another example is gnome contacts app. I do have my google account configured through gnome online accounts. Thus gnome contacts displays more than 1100 of my google contacts on initial launch. Without these patches applied gnome contacts app is hardly useable using keyboard only. Navigating between items takes a couple of seconds. Navigating to e.g. 50th item is extremelly difficult if not inpossible. After applying these patches gnome contacts is finally usable at least to an extend we can start hunting other accessibility issues within that app. The list of contacts is accessible, it is even possible to go into selection mode and check multiple contacts. Responsiveness is all great here. I can just make orca to freeze when trying to use flat review while gnome contacts is in focus. While editing contact it is verry difficult to get into the form where we can make edits, interactive controls when editing a contacts are not clearly labelled but that is something that is eventually fixable easily. So I apologize once more for describing various usage scenarios even out of scope of this issue however I believe it is extremelly important to understant how much this may affect upcoming gnome accessibility development.
Thanks for the testing, Peter. Do you know whether your CPU utilization goes up to 100% when Orca freezes? You'd probably need to go to a console in order to check that. The freezes might be AT-SPI crashes--for some reason, orca freezes and starts loading the CPU if there is a C crash, rather than aborting. Anyway, I'll see if I can reproduce. It seems like the patches are worth getting into 3.18.
It was indeed a crash. I've fixed and pushed to master. at-spi2-core: b2c8c4 at-spi2-atk: b85069 libatspi should still recognize the old API (used by the current qt-at-spi, and by at-spi2-atk before the last commit), but the older libatspi is incompatible with the newest at-spi2-atk, so I've upped the version dependency.
Thank you verry much, now I can no longer reproduce crashes when Thunderbird is running and possibly elsewhere too. I am running self-built master branch of both at-spi2-core and at-spi2-atk on Arch linux with Gnome 3.16 for some two hours of continous usage. Unfortunatelly lag and CPU increase is still happening for me when switching folders with large message lists in Thunderbird.
Oh sorry for double comments is this a good reason for politelly asking qt-at-spi guys about adapting to this updated API?
See bug 754048 for a possible regression.