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

[Luke Yelavich <themuso ubuntu com>]

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