GNOME Bugzilla – Bug 382408
Significant sluggishness when navigating in OOo Writer tables
Last modified: 2006-12-05 19:11:41 UTC
Please describe the problem: When arrowing among the cells of a table within in an OOo Writer document, Orca becomes significantly sluggish. Steps to reproduce: 1. Open table-sample.odt (to be attached) 2. Arrow down from the top of the document into the table Actual results: Orca speaks normally until the table is entered. Upon entering the table, there are significant pauses between the keyevent and the speaking of the cell contents. Expected results: There would not be significant pauses between the keyevent and the speaking of the cell contents. Does this happen every time? Yes. Other information: Down arrowing a single time to move focus into the table resulted in the following being written to debug.out: StarOffice: locateInputLine: incorrect paragraph count. StarOffice: locateInputLine: incorrect paragraph count. StarOffice: locateInputLine: incorrect paragraph count. StarOffice: locateInputLine: incorrect paragraph count. StarOffice: locateInputLine: incorrect paragraph count. StarOffice: locateInputLine: incorrect paragraph count. StarOffice: locateInputLine: incorrect paragraph count.
Created attachment 77687 [details] sample Writer document in which the sluggishness was found
Comment #5 of bug #349956 has some code that adds in some timing values that would help track this down. We should prolly check this in commented out so it's easy to uncomment and use them.
Created attachment 77692 [details] debug info with timings included Looks like I got out of the "full debug.out" habit. Sorry.... I added the timing code you mentioned along with the full debug.out stuff. Bad things happen around line 580 in the attached. Lots of util.getObjects looking at child x HTH.
I just tried to reproduce the sluggishness and I'm not seeing it. This is on my Acer Ferrari 3400, under Ubunto Edgy with OOo v2.0.4 and Orca from CVS HEAD (and using the Festival voice). Can you confirm that these three lines in your ~/.orca/user-settings.py are commented out please? #orca.settings.useBonoboMain=False #orca.settings.debugEventQueue=True #orca.settings.gilSleepTime=0 (That was the problem last time with the Print dialog).
They are indeed commented out. I just tried this on one of my desktops and the problem is also there. So that's one Edgy box, one Feisty box, both with Orca from CVS HEAD, both with OOo v2.0.4, and I tried with both Festival and DECTalk. The sluggishness -- along with the number of times I get StarOffice: locateInputLine: incorrect paragraph count. -- seems to increase when I'm using speak row rather than speak cell. Are you getting the repeated instances of incorrect paragraph count?
> Are you getting the repeated instances of incorrect paragraph count Yes. Okay, I'll have a look at it further tomorrow (and the other two OOo problems). Thanks.
I'm now seeing the sluggishness if I have settings.readTableCellRow set to True (I was originally testing with it set to False).
The "incorrect paragraph count" is a bogus debug message when emitted by the StarOffice.py script when running with Writer. I incorrectly assumed that the locateInputLine() script would only be called when running with Calc, and therefore there should only be one component of type "paragraph". This will need to be reworked.
Created attachment 77741 [details] [review] Patch to hopefully fix the problem. I've also checked the attached patch into CVS HEAD. Seems to work nicely for me. Joanie, could you try it out and see if it also fixes it for you please? Thanks.
Works nicely for me too. Thanks!
Seems to be working much better. thanks much
Thanks guys. Closing as FIXED.