[Kde-accessibility] [Accessibility-atspi] D-Bus AT-SPI - The way forward

[Aaron M Leventhal]

Mark, did you try testing Orbit with a direct connection?
This suggestions was from George Kraft:

> How are your Orbit2 results impacted if your $HOME/.orbitrc has set 
> the following?
> 
> ORBIIOPIPv4=1
> ORBLocalOnly=1

- Aaron




Mark Doffman <mark.doffman at codethink.co.uk> 
Sent by: accessibility-atspi-bounces at lists.linux-foundation.org
12/05/2007 11:56 AM

To
accessibility-linux-foundation <accessibility at lists.linux-foundation.org>, 
accessibility-atspi-linux-foundation 
<accessibility-atspi at lists.linux-foundation.org>, 
gnome-accessibility-devel <gnome-accessibility-devel at gnome.org>, 
kde-accessibility <kde-accessibility at kde.org>
cc

Subject
[Accessibility-atspi] D-Bus AT-SPI - The way forward






Hello all,

Available at http://live.gnome.org/GAP/AtSpiDbusInvestigation is the
results of an investigation into a move of the AT-SPI interface to a
D-Bus transport. The investigation mainly looks at the relative
performance of ORBit and D-Bus, but also details some architectural
issues and a preliminary task list.

In brief:

Performance:

GOK and Orca were profiled to get a good idea of the type of traffic on
the AT-SPI interface. Using this information the performance of some of
the most common method calls were tested in D-Bus and ORBit.

D-Bus is undoubtedly slower at most of the common method calls, 5-6x
slower when making a call that passes one int as an argument. When
passing more data per call this speed difference decreases. ORBit takes
a long time to pass an Object reference, making D-Bus up to 1.5x faster
at these method calls.

Although D-Bus is the slower transport, looking at the calls made by
Orca and GOK, we feel it will be possible to provide sensible caching
that should mitigate this effect.

Tasks:

For a switchover to D-Bus a number of core libraries will need to have
the transport mechanism changed: cspi, pyatspi, GAIL. There will also
need to be a new Java accessibility back end. Some core D-Bus work is
also needed, in the areas of interface specification, bindings and
possibly optimisation.

If you are interested please go and take a look at the wiki page. We'd
really like to get every ones opinion on what the way forward for AT-SPI
is in terms of its transport mechanism.

Thanks

Mark

-- 
Mark Doffman, Codethink Ltd. - http://codethink.co.uk

_______________________________________________
Accessibility-atspi mailing list
Accessibility-atspi at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/accessibility-atspi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-accessibility/attachments/20071205/b5aeed84/attachment.html