After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 569428 - At-spi should include a reciprocal relationship for NODE_CHILD_OF
At-spi should include a reciprocal relationship for NODE_CHILD_OF
Status: RESOLVED FIXED
Product: at-spi
Classification: Platform
Component: api
1.25.x
Other All
: Normal major
: ---
Assigned To: Li Yuan
Li Yuan
Depends on: 569427
Blocks: 554688 568158 569430
 
 
Reported: 2009-01-28 07:17 UTC by Joanmarie Diggs (IRC: joanie)
Modified: 2009-11-06 08:33 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24


Attachments
The patch I used in my tests. (3.28 KB, patch)
2009-01-28 07:22 UTC, Joanmarie Diggs (IRC: joanie)
committed Details | Review

Description Joanmarie Diggs (IRC: joanie) 2009-01-28 07:17:57 UTC
+++ This bug was initially created as a clone of Bug #569427 +++

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!
Comment 1 Joanmarie Diggs (IRC: joanie) 2009-01-28 07:22:51 UTC
Created attachment 127380 [details] [review]
The patch I used in my tests.

As I commented on the Atk patch, I don't care what the relationship is called. :-) We just need it implemented. This is the patch I used when performing the tests I described in the opening comment.
Comment 2 Willie Walker 2009-01-28 13:32:45 UTC
Awesome stuff!  This really improves things a lot.
Comment 3 Willie Walker 2009-05-01 14:49:56 UTC
Li - what are your thoughts on this?  I think this would be a great addition for 2.28.
Comment 4 Li Yuan 2009-11-06 08:27:48 UTC
Review of attachment 127380 [details] [review]:

Patch has been committed. Thanks for the patch!