[orca-list] Concerns about Orca's performance

[Jacob Schmude <j schmude gmail com>]

Hi everyone
Well, I'd like to bring this issue up and see what comes of it. I've  
noticed that, in most situations, Orca can sometimes be very laggy on  
all but high-performance desktops. Let me give a few examples (from my  
netbook, but this can apply to almost any single core and lower- 
performing dual core systems):
1. Bringing up the file open dialog in most applications happens  
quickly, but it can take up to two seconds for Orca to respond and  
notify that the dialog is up. Orca itself doesn't seem to lag the  
desktop at all, but there's a significant delay before I'm notified  
about certain events. This applies to any dialog, file open is the  
quickest example however.
2. Sometimes when typing into text fields in scripted applications or  
those based on Xul such as Firefox and Thunderbird, my typing is  
significantly lagged. For example, I finish typing a sentence and yet  
only two words have been typed, with the rest of the letters slowly  
appearing one about every half second. If I attempt to backspace or  
otherwise navigate, then each letter begins to be spoken along with  
the entire desktop slowing down until the typing has finished. Note  
that I have keyboard echo turned off completely.
3. When navigating any table for the first time, i.e. the first select  
once a table has been focused, a very odd behavior starts and  
continues for a second or so. Essentially the first column of the  
table gets repeated over and over again while getting interrupted each  
time. It's a bit hard to explain, so I'll give an example of what I  
here. In the file open dialog, say I'm navigating to the item that is  
called "Desktop," and it is one down from where I have focused when  
entering the table. This is what I hear:
Desktop, image image im im im image desktop today. The column focused  
gets spoken but then gets interrupted by an image, which I'm assuming  
is an icon representing the file, and orca repeatedly interrupts  
itself to try and start reading the entire row and eventually settles  
down. Attempting to navigate while this is happening can cause a  
number of odd behaviors such as Orca crashes, queued keystrokes, or  
desktop freeze.

These are the three examples I can reproduce reliably of some of the  
performance issues I've had with Orca for a long time (way before the  
code refactor). These will be noticed more on a lower spec machine  
than a high-powered quad core, for example, and I'm really starting to  
feel them now on my netbook. HOwever, the os doesn't seem to make a  
difference, be it Opensolaris or Linux or FreeBSD, or even OS X. I've  
also tried espeak, festival and ibmtts (on Linux only for ibmtts  
obviously) both with gnome-speech and speech dispatcher and with every  
audio system each platform provides. I don't notice any difference, so  
I've ruled out audio or synthesizer-specific issues for the moment.
I can provide debugging logs for each of these as I can easily  
reproduce them. I wasn't sure if there's already a bug tracking issues  
such as this, or if anyone else is having them. Is anyone else seeing  
this? Do braille users notice this type of lag too or is it specific  
to speech? Is there a bug tracking this or should a new one be opened?
Thanks



   The major difference between a thing that might go wrong and a  
thing that cannot possibly go wrong is that when a thing that cannot  
possibly go wrong goes wrong it usually turns out to be impossible to  
get at or repair.
        --Douglas Adams