GNOME Bugzilla – Bug 569427
Atk should include a reciprocal relationship for NODE_CHILD_OF
Last modified: 2009-11-09 03:18:01 UTC
A screen reader providing access to an expanded item in a tree level is expected to include the number of items contained/displayed by that expanded node. In a tree which manages its descendants, the items contained in the expanded node are not children in the accessible hierarchy. Therefore, the only way to determine the number of *functional*/displayed children of an expanded node is to traverse the tree row by row looking for the NODE_CHILD_OF relationship and seeing if it happens to point to the expanded item under consideration. This is at best tedious and slow. In enormous trees in which most items are expanded, the system can grind to a halt. Literally. Here are some sample numbers taken by using Orca and navigating amongst items in gconf-editor. * "new way" == addition of a NODE_PARENT_OF relationship added to Atk, AT-SPI, and Gtk+/Gail and then used in Orca. * "old way" == current state of affairs * The second number is the number of immediate child nodes (i.e. the objects which exposed NODE_CHILD_OF for the object of interest. * The final number if the number of seconds it took Orca to obtain the number of immediate child nodes. =========================== 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 1 0.000760793685913 old way 1 38.6404290199 Personally I think the performance improvement is staggering and would ask that you seriously and immediately consider implementing such a relationship. Thank you very much in advance for your consideration!
Created attachment 127379 [details] [review] The patch I used in my tests. I don't care what you call the relationship. :-) Just implement it and let us know. This is the Atk patch I used when performing the tests I described in my opening report.
Li - what are your thoughts on this? I think this would be a great addition for 2.28.
Sure. Will work on this.
Review of attachment 127379 [details] [review]: Thanks very much for the patch.
Should we move the new item to the end of the enum? The git atk is currently not binary-compatible with 1.28.0. I'm not sure off-hand if this violates any GNOME guidelines, but, either way, it worries me a bit, since it could cause subtle problems if someone upgrades atk without upgrading gail, and FF and OO would behave differently depending on which ersion of atk they were compiled against.
I have made the change. Thanks for your remind Mike.