Re: [orca-list] Misteries of low performance of Orca and distros

[Alex Midence <alex midence gmail com>]

That was a fascinating post!  As to what lengths developers of windows
screen readers go to to make their product more responsive, the only thing
(and this is a guess, mind you) which comes to my mind is the choice of
programming language.  The infrastructure of the program is written in a
compiled language like C or C++ and an interpreted language is used for
customization i.e. scripting.  Jaws, for instance, is written in c++ and
uses its own, in-house interpreted language called jaws scripting language
for customization.  Window Eyes uses c++ for the code and can use stuff like
visual basic or, in some cases, I seem to recall seeing Perl for scripting.
NVDA does same thing, c++ for infrastructure and Python for scripting.
Orca, on the other hand, appears to be written entirely in Python as are
lots of other accessibility components from what I was able to gather.  I
don't know how much difference this makes but, this is the best guess I can
come up with for the difference.  Manpower is another factor but, NVDA
doesn't seem to have the amount of people working on it that I'd imagine a
commercially produced program like JFW and Window Eyes would have.  There's
another screen reader out there which is called Access to Go or something
like that and then there's Supernova which has a screen reading component.
I know very little about these products so can't say how they do things.


Regards,
Alex M


-----Original Message-----
From: orca-list [mailto:orca-list-bounces gnome org] On Behalf Of Luke
Yelavich
Sent: Monday, July 29, 2013 7:34 PM
To: orca-list gnome org
Subject: Re: [orca-list] Misteries of low performance of Orca and distros

On Mon, Jul 29, 2013 at 11:55:03PM EST, Luciano de Souza wrote:
> Hi listers,
> I am using Orca 3.2.0 and Ubuntu 10.10, but I really need to upgrade it.
> However, I am facing severe issues about performance. I have a Entel
> I5 processor with 4 gigabytes of RAM. It's not a bad machine, but, 
> under Linux environment, the performance has never been good.

I don't think you are referring to performance, so much as you are referring
to Orca responsiveness. Linux of any flavour will certainly perform quite
well on your system, given you have plenty of RAM. I think it is well known
that screen readers in Windows tend to be much more responsive, although I
don't know what lengths screen reader developers go to, to achieve such
responsiveness. I do however, have a pretty good idea as to why Orca is not
as responsive as it possibly could be, and this is always something that the
GNOME accessibility development team are aware of, and are trying to
address.

I am not going to go indepth here as to how the whole accessibility
framework works, I believe there is some good documentation about the
details on the GNOME Accessibility wiki,
http://live.gnome.org/Accessibility. The key point here however, is that
there are essentially 3 components. The application, the assistive
technology provider, otherwise known as at-spi, and then the assistive
technology, aka Orca. You may have heard of Dbus. Dbus is a technology that
was developed to help with inter-process communication (IPC). THe GNOME
accessibility framework uses Dbus to communicate between the application,
at-spi, and Orca.

When Orca is started, one of the things it does is register itself with
at-spi, and one part of this registration is registering a listener with
at-spi for keyboard events. This is so Orca can act on Orca specific
commands, and it needs to be able to do so before the application does. So
lets step through what happens when a user is say, navigating a dialog box,
and the user presses tab to move to the next control in the window.

1. THe user presses the tab key.
2. The toolkit that the application is based on, in most cases this is GTK,
picks up on the key press, but before it passes it through to the
application, it checks to see whether there are any key listeners registered
with itself. In the Orca case there is.
3. The listener is then called, and sends the keystroke via Dbus to at-spi.
4. At-spi checks for any registered key listeners from assistive
technologies.
5. The Orca key listener is found, and called. Now its up to Orca to decide
what to do with that tab key press.
6. Orca checks its own database of settings, and if tab is associated with
an Orca command, a signal is sent back to at-spi, and then to the
app/toolkit, that the keyboard command should be discarded. Otherwise a
signal is sent back to the app/toolkit indicating the command should be
passed through to the application.
8. At-spi then signals the application toolkit via Dbus to pass through the
key press to the rest of the toolkit/app to be acted on.
9. The application/toolkit then signals a widget focus change, and the whole
dance is repeated back and forth to signal Orca, and for Orca to find out
about the widget in question, although its likely that at-spi has cached
relevant data about the widget, so communication is not always needed with
the application.

This process is followed for all keyboard input when Orca is running, even
when you are typing text in an editor. There is also more back and forth
between orca and at-spi when flat review is used, as Orca needs to be able
to find widgets in a window when moving up and down by line, or moving
accross via word/character.

The observant among you may be wondering why the toolkit is required to
listen for key presses, and send them back to at-spi. This is due to a lack
of functionality in the X window system. In ideal circumstances, at-spi
should be able to register with X, and get keyboard events itself, and at
one point there was an X extension to do so. However from what I've read,
this extension was buggy and not maintained, so it fell out of use, thus GTK
had to be extended to do the listening for at-spi, which in turn introduced
further back and forth between the two processes to make things work
properly for Orca. Fortunately, this is likely going to change with the
advent of Wayland, and Canonical's Mir display server, at which point, GTK
will not be required to do any key listening for at-spi. Hopefully this
change will result in a slight responsiveness increase for Orca use,
although its not known just how much better things will be until things
change.

As for your installation issues, I encourage you to raise them on the
relevant distro lists, i.e the Vinux list or the Ubuntu accessibility list,
and I am sure folks there will be more than happy to help you try and work
out what is going wrong.

I hope this helps, and has educated a few folks as to how some of the
infrastructure works.

GNOME accessibility devs, feel free to chime in and correct me if I don't
have things quite correct.

Luke
_______________________________________________
orca-list mailing list
orca-list gnome org
https://mail.gnome.org/mailman/listinfo/orca-list
Visit http://live.gnome.org/Orca for more information on Orca.
The manual is at
http://library.gnome.org/users/gnome-access-guide/nightly/ats-2.html
The FAQ is at http://live.gnome.org/Orca/FrequentlyAskedQuestions
Log bugs and feature requests at http://bugzilla.gnome.org Find out how to
help at http://live.gnome.org/Orca/HowCanIHelp