I've noticed the poor performance in lists in Thunderbird for some time.  The recent changes in the Lanikai series offers the advantage of identifying expanded and collapsed threads.  I like that part but navigating in the lists is particularly slow and to really see how slow, try using flat review while this list is focused.

I notice this as well. However here are a few more observations:
* The change in thunderbird occurred between 3.0.9 and 3.1.
* Since this change in thunderbird Braille actually responds much faster for me.
* Speech response time I think has slowed down in the message list.

So I wonder what is different about what orca is doing to generate the Braille output compared with what it is doing for speech output to lead to this difference (significantly different response time, Braille is almost instant for me but speech is in seconds).

Not knowing the internals of orca, but thinking logicaly about this, the delay must be coming from something orca is doing for speech so probably the change needs to be made to orca.

When I think of performance issues with Thunderbird, the most glaring one for me is you use flat review while in the message list for any mail folder.  Response can take up to fifteen seconds or more.  I do not have any Braille devices so cannot comment on Braille.

I think looking at flat review here would not be helpful. To enter flat review in other applications can also be slow (admittedly thunderbird is one of the most slow apllications for switching to flat review) so the problem is more generally what is done to enter flat review.

If I understand what flat review does (as you enter it orca finds out information about all the controls of the window, taking a snapshot of the controls) then fixing the responsiveness of the message list for normal navigation should help flat review in thunderbird.

I am not saying forget about the response time for entering flat review, rather it may just be better treated as a separate bug report.

Just confirming what has been said.
Orca takes too long to respond when you access a folder with many messages.
The interesting thing is that I can not switch to another application by pressing alt + tab.

(In reply to comment #5)
> Just confirming what has been said.
> Orca takes too long to respond when you access a folder with many messages.
> The interesting thing is that I can not switch to another application by
> pressing alt + tab.

I guess you mean when waiting for orca to speak the item which is selected in the message list. I actually notice this as orca blocks everything until it speaks the item.

If orca were to allow itself to be interrupted this while not solving the bug would at least ease things a bit as I could cursor through the list a bit quicker (particularly in my case as I could start reading it in Braille almost instantly).

(In reply to comment #6)
> I guess you mean when waiting for orca to speak the item which is selected in
> the message list. I actually notice this as orca blocks everything until it
> speaks the item.
> 
Exactly.
> If orca were to allow itself to be interrupted this while not solving the bug
> would at least ease things a bit as I could cursor through the list a bit
> quicker (particularly in my case as I could start reading it in Braille almost
> instantly).

Hmmm!
I think that the problem is caused because thunderbird sends to many events to be processed by orca.
If I understand correctly how Orca has been implemented, all events generated by applications are placed in a single queue to be processed by orca. Thus they must be processed in order of arrival. 
If the queue has events generated by thunderbird and an event generated by other application is placed in the queue, the new event will be processed after all events generated by thunderbird were processed.
This is my understanding, I could be wrong.

(In reply to comment #7)
[...]
> > If orca were to allow itself to be interrupted this while not solving the bug
> > would at least ease things a bit as I could cursor through the list a bit
> > quicker (particularly in my case as I could start reading it in Braille almost
> > instantly).
> 
> Hmmm!
> I think that the problem is caused because thunderbird sends to many events to
> be processed by orca.
> If I understand correctly how Orca has been implemented, all events generated
> by applications are placed in a single queue to be processed by orca. Thus they
> must be processed in order of arrival. 
> If the queue has events generated by thunderbird and an event generated by
> other application is placed in the queue, the new event will be processed after
> all events generated by thunderbird were processed.
> This is my understanding, I could be wrong.
I am also under the same impression as you about the event processing. My only question is here, is it thunderbird sending alot of events or is orca taking a long time over processing the event(s)? Also I am still puzzled over why Braille is updated almost instantly but speech isn't, may be its that if there are multiple events, if Braille doesn't change the text on the later events then may be I just cannot observe a later update at the same time speech starts talking.

I think time to start doing a debug, I'll get onto that right away.

Oh, possible I forgot attached a debug.out file when I doed my bugreport? Very sorry.
Just a moment.

Attila

Created attachment 174139 [details]
Debug.out file

Sorry, this file maked 2010. 10. 25, when I doed my bugreport, unfortunately I forgot attaching.
Possible this is a good startup point, please look.
See my first comment what can I do when I maked the debug.out file.
Unfortunately the debug.out file is too large when I try attaching, I compressed the file with .zip compression.

If this file not enough, I doing welcome new debug.out file, but unfortunately tomorrow entire day I am not in home.

Attila

Created attachment 174143 [details]
Debug showing what is going on (on English system).

Sorry for repetition, Attila my Hungarian isn't up to much and trying to wade through the messages and not necessarily knowing what orca was putting out didn't help me.

What I see from my debug is that there doesn't seem to be many events when I move, this implies orca is possibly doing a lot of processing for speech. I have a few ideas of my own to try and track this down.

Created attachment 174150 [details]
Debug with some timing details

I made a small patch to orca so that the time would be put out with the debug messages and then reran orca in debug mode. This is quite revealing.

The attached debug shows that in producing output orca is fairly well at the same time until positioninlist where it jumps about 6 seconds. Admittedly my patch just uses the time module in python which may not be the most accurate time module, I do though think it should be accurate enough to show a gap of 6 seconds and it does show it occurring at the same point (the time when thunderbird is first given focus and the second being when I move in the list).

When I'm in the tree that contains the folders and then hit the tab key to
focus on the trash folder, Orca takes too long to announce the item that
receives focus. 

I found in the debug output to many object:property-change:accessible-name
events. To be mor precise, 754, although I can not confirm that all are related
to thunderbird.
It seems that is one event to each message presented in the screen.

I have convinced myself where the problem is.

I just added the following line to orca-customizations.py

import orca.settings
orca.settings.onlySpeakDisplayedText=True

and this has made the bug go away.

Reason it works, it makes orca not try and get the position details. I don't think orca was reading the position anyway before I set this but it may affect things elsewhere. If orca doesn't succeed in getting the position information in the message list anyway, then could the thunderbird script be made to stop orca trying to do this in the message list so that if the user desires position information elsewhere then they can have it?

(In reply to comment #14)
> I have convinced myself where the problem is.
> 
> I just added the following line to orca-customizations.py
> 
> import orca.settings
> orca.settings.onlySpeakDisplayedText=True

You do not need to include this line, there is an option in preferences to do the same thing and it can be configured per application.

> and this has made the bug go away.

Yes, I can confirm.

> Reason it works, it makes orca not try and get the position details. I don't
> think orca was reading the position anyway before I set this but it may affect
> things elsewhere. If orca doesn't succeed in getting the position information
> in the message list anyway, then could the thunderbird script be made to stop
> orca trying to do this in the message list so that if the user desires position
> information elsewhere then they can have it?

There is also an option to toggle the read of position. I tried uncheck this option but the bug didn't go away.

Created attachment 174159 [details] [review]
Patch which checks if position is to be reported before finding the position

I think this patch will help ease some of the problems but will not fix it entirely.

What I noticed is that there is the setting onlySpeakDisplayedText and enablePositionSpeaking. The latter explains why thunderbird wasn't telling me the position in the message list even when onlySpeakDisplayedText was False. However although enabledPositionSpeaking was also False, the check on this setting was not being done until after the position was being found, hence in thunderbird I noticed a delay while it found the position which I wasn't being told.

This patch moves that check of the enablePositionSpeaking setting to before finding the position. If one applies the patch, the only people who will still notice the bug will be those who have the position reported.

After apply the patch created in coment #16, Orca does not announce the position, even if the speak child position is set.

Created attachment 174191 [details] [review]
Corrected patch for early checking of position settings

Thanks Jose, I had made a mistake when separating parts of the logic in the later if statement. This patch should work (I have tested it with speaking child position on and off this time).

(In reply to comment #18)
> Thanks Jose, I had made a mistake when separating parts of the logic in the
> later if statement. This patch should work (I have tested it with speaking
> child position on and off this time).

Works fine, thanks.
I found a problem but I am not sure if it is related to the patch.
If speak child position is on in the global preferences and it is of in the preferences for thunderbird, the position is announced.

(In reply to comment #19)
> (In reply to comment #18)
> > Thanks Jose, I had made a mistake when separating parts of the logic in the
> > later if statement. This patch should work (I have tested it with speaking
> > child position on and off this time).
> 
> Works fine, thanks.
> I found a problem but I am not sure if it is related to the patch.
> If speak child position is on in the global preferences and it is of in the
> preferences for thunderbird, the position is announced.

I have tried that with my distributions supplied version of orca (2.32..0) and with the version from git with my patch applied and neither show the bug you describe. Also thinking about the changes in my patch it shouldn't affect the actual spoken output, its just moving the checking of the settings earlier so that position isn't calculated unecessarily. I am quite sure of my patch, I really took care with the moving the checks from one if to the earlier one after getting it wrong the first time.

Could you try with an unpatched version of orca and then we have a clue whether it is my patch causing your issue.

(In reply to comment #20)
> > Works fine, thanks.
> > I found a problem but I am not sure if it is related to the patch.
> > If speak child position is on in the global preferences and it is of in the
> > preferences for thunderbird, the position is announced.
> 
> I have tried that with my distributions supplied version of orca (2.32..0) and
> with the version from git with my patch applied and neither show the bug you
> describe. Also thinking about the changes in my patch it shouldn't affect the
> actual spoken output, its just moving the checking of the settings earlier so
> that position isn't calculated unecessarily. I am quite sure of my patch, I
> really took care with the moving the checks from one if to the earlier one
> after getting it wrong the first time.
> 
> Could you try with an unpatched version of orca and then we have a clue whether
> it is my patch causing your issue.

After reapplying the patch, the problem reported in comment #19 has gone.
It's like we say in Brazil: I must have stepped on the ball.
Thanks.

Michael, your patch is fantastic.
When I turned off with Orca application preferences the speak child position feature and applied your patch, I see very good performance result. My inbox have 1489 messages now, the list navigation is absolute fast.
When I jump last message for example the list with end key, I hear 0,1 second later the message subject and the sender. When I jump next unread messages folder with n key, after I answering yes the popup question, I hear the selected message with this time result.

Unfortunately if I turn on again the speak child position feature with Orca application preferences, I get back the slow time performance result.

Attila

(In reply to comment #22)
> Michael, your patch is fantastic.
> When I turned off with Orca application preferences the speak child position
> feature and applied your patch, I see very good performance result. My inbox
> have 1489 messages now, the list navigation is absolute fast.
> When I jump last message for example the list with end key, I hear 0,1 second
> later the message subject and the sender. When I jump next unread messages
> folder with n key, after I answering yes the popup question, I hear the
> selected message with this time result.
> 
> Unfortunately if I turn on again the speak child position feature with Orca
> application preferences, I get back the slow time performance result.
> 
> Attila

This is great to hear, the patch seems to be working precisely as I expected.

Unfortunately my patch was never intended to speed things up when you have the speak child position setting enabled, its the process of finding the position which is slow.

If its any comfort, at least we now know which specific bit of code is causing the slow performance and hopefully it can be seen to.

(In reply to comment #23)
 
> Unfortunately my patch was never intended to speed things up when you have the
> speak child position setting enabled, its the process of finding the position
> which is slow.
> 
> If its any comfort, at least we now know which specific bit of code is causing
> the slow performance and hopefully it can be seen to.

Seems to me that we should modify the description of this bug and open another bug to deal with the slow performance when the speak child position is enabled.
Part of the problem is caused because the position is always calculated, even if not shown.
This is fixed by the attached patch and it could be pushed.

I was going to change the description of this bug to orca calculates position even if it is not to be spoken, so leading to significant delays in some applications (eg. large email folders, over 500 messages, in thunderbird gives me about a 6 second delay).

However I have been unable to find how to change the description, could someone else do this (does it require the bug reporter to do this?).

In addition I have committed the bug #634642 for improving the performance of finding the position.

This patch is fantastic! I just opened up my 'All Mail' folder in the gmail structure which contains over 11,000 messages presently.  I didn't get exact time figures but it was nearly immediate that the folder was spoken and the message item read.  I could jump from the top to the bottom and arrow key movements and all happened in less than a second.

This patch needs to be committed/pushed big time.  Joanie, I hope you are listening.

(In reply to comment #27)

> This patch needs to be committed/pushed big time.  Joanie, I hope you are
> listening.

Who, me? Huh? <grins>

It sounds awesome. I want to run the regression tests first. In the meantime, if y'all could keep testing to be sure there are no unexpected side effects, I'd appreciate it.

(In reply to comment #28)
> (In reply to comment #27)
> 
> > This patch needs to be committed/pushed big time.  Joanie, I hope you are
> > listening.
> 
> Who, me? Huh? <grins>
> 
> It sounds awesome. I want to run the regression tests first. In the meantime,
> if y'all could keep testing to be sure there are no unexpected side effects,
> I'd appreciate it.

Any further with committing the patch, been using it here continually since I created it and find no problems.

Also regarding the position finding code which causes the significant delay, I've tracked it down to a specific loop and documented this in bug #634642. I suspect it may be outside orca's control to solve the performance issue of finding the specific position.

Comment on attachment 174191 [details] [review]
Corrected patch for early checking of position settings

http://git.gnome.org/browse/orca/commit/?id=ffecc80db3ddf2d1139cd0690b471f70a73c75ed

Joanie, possible committing the last Thunderbird related attachment with Orca 2.32.2 future maintenance version?
Following attachment are committed in november with git master version only I think bug 634642 related:
http://git.gnome.org/browse/orca/commit/?id=ffecc80db3ddf2d1139cd0690b471f70a73c75ed

Attila

 calculates position ok, as Michael requested by Michael in comment 25 I'm changing the smmary to orca calculates position even if it won't be spoken. and closing this bug.