[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