[Accessibility-atspi] AT-SPI2 TODO List

Mike Gorse mgorse at novell.com
Tue Jun 15 14:48:32 PDT 2010


Hi Mark,

Thanks for the list.  Comments in-line.

> ## Performance ##
>
> Moving AT-SPI from CORBA to D-Bus has lead to a decrease in performance.
> D-Bus IPC is not as fast as CORBA for the AT-SPI API. This has been
> mostly mitigated by the use of client-side caching of accessibility
> information.

I was noticing last week that Orca can be very slow with at-spi2 and 
Firefox and that most of the cpu cycles (perhaps 2/3) were taken by Orca. 
I ran a profiler to try to figure out if there was anything in particular 
that was slowing things down in Orca but didn't notice anything standing 
out in particular except perhaps the dbus calls and there just being a lot 
of them.  I decided to try to figure out if dbus-python introduced a lot 
of overhead and ran a benchmark where I called GetConnectionUnixProcessID 
100000 times both in C (using libdbus) and using dbus-python, as well as 
creating a C function to make the dbus call and calling it from Python 
using pygi.  The results were as follows:
C only: 3.6 secs
dbus-python: 7.9 secs
C/pygi: 6.3 secs

I cannot assume that this test reflects actual at-spi usage, but, still, 
I'm concluding that the original proposed approach of having a 
gobject-based caching mechanism with a Python wrapper would probably be 
faster than the current pyatspi code, so I would like to experiment with 
this approach at some point.  The code in at-spi2-atk/cspi could be used 
as a base but would need some refactoring to be in line with the urrent 
dbus api and make the C api more GI-friendly (ie, have errors returned 
through a gerror).  A compatibility layer for the old cspi could hopefully 
be implemented as a thin wrapper around this library.  This would not 
solve all of the performance issues, but I suspect that there will be no 
one magical way to improve performance and anything that helps some would 
be useful.

> ### Re-entrancy ###
>
> Method calls in pyatspi are re-entrant. This means that they try to
> 'fake' a syncronous call by re-entering the GMainLoop while making the
> method call. This has caused issues in the past where there were far too
> many levels of re-entrancy leading to performance degredation on lower
> performing machines and failures of the Orca test cases.

I believe I've fixed the "maximum recursion depth exceeded" issue.  The 
intention with the AsyncAccessibilityBus, I believe, is to queue events 
until a function call made o the Async bus was completed, but this was not 
happening.  Events would be placed in a queue to be dispatched when the 
main loop became idle, but the bus would re-enter the main loop when 
waiting for a reply from a function call, resulting in events being 
delivered while waiting for a reply from a function call.  If the event 
handler called an at-spi function, then we could re-enter the main loop 
yet again, possibly triggering another event to be dispatched and so on. 
Anyway, I've made the bus "freeze" event delivery while calling a 
function, which helped.

> Re-entrancy has also lead to failures when using AT-SPI D-Bus with
> accerciser.

It would cause a crash with accerciser since it invoked at-spi methods 
upon receiving a gtk signal, resulting in the main loop bein re-entered, 
which presumably caused more events to be fired that gtk was not 
expecting.  I've fixed this in accerciser 1.11.1, by deferring the 
handling of the signal to an idle.  I haven't found any other similar 
crashes, but I don't know for sure that it is the only such issue.  It may 
only be an issue for applications which inspect themselves via at-spi, 
since otherwise at-spi calls are not generated synchronously as gtk 
signals are generated.

> ### KDE ###
>
> Currently the releases are GNOME specific. Ideally it would be possible
> to use these releases with KDE.

I'm not sure what you mean here, other than that they are hosted on 
gnome.org and there are dependencies on glib (is this a problem for QT?)

> ### JHBuild ###
>
> AT-SPI D-Bus has been removed from the JHBuild system. It will need to
> be added back in for integration in to GNOME.

I filed a bug for this:
http://bugzilla.gnome.org/show_bug.cgi?id=619659

> ## Firefox ##
>
> Firefox 3.6 and later crash when using AT-SPI D-Bus. It is an extremely
> high priority to fix this issue.

Afaik this is fixed as of at-spi2-atk 0.3.2.  If people are still seeing 
this, then let me know--I am using Firefox 3.6.3 and no longer get the 
crash.  I moved cache updates from children-changed signals into an idle, 
to fix a bug where we were sending AddAccessible signals for objects that 
were not yet fully initialized (ie, the role would still be set to 
UNKNOWN), and this also fixed the Firefox crash for me.

Hth,
-Mike G-


More information about the Accessibility-atspi mailing list