when in a word document, navigation throughout a document with the braille display is slow

[nvaccessAuto]

Reported by zstanecic on 2015-03-24 13:57 steps to reproduce:

1. open any structured or normal written word document. Press the navigation keys on your braille display. you should use up / down arrow keys simulation and scrolling keys.. After that, you will notice an one second lag.. It's present in latest snaps and in the stable 2015.1.

[nvaccessAuto]

Comment 1 by dkager on 2015-04-25 20:45 I can't reproduce this under Windows 7, Office 365 (i.e. currently 2013), Alva BC640 display and NVDA-next with a 650-page Word document with formatting.

My only observation is that panning left/right within the same line is very fast but anything that moves the cursor to another line takes 250-500 ms. The delay is constant, I'm just not good at estimating. A few things that cause this cursor movement:

• Panning past the end of a line.
• Using the thumb keys to read by line, which I guess simulate arrow keys.
• Using the arrow keys, either on the braille display or on a regular keyboard. This behavior obviously isn't specific to braille. I'm not sure if this is what is being reported or if I just can't reproduce this bug with my setup.

[nvaccessAuto]

Comment 2 by jteh on 2015-04-26 02:36 Pretty sure this is what's being reported. It's probably just that your system is faster, so the delay is shorter. It's not specific to braille as such, but it'll be a lot worse with braille than without because braille causes more queries to Word.

We might be able to tighten this up with some caching, but there are always going to be performance problems here because of the way we have to get information from Word. Switching to UIA for Word will probably improve this, but aside from being a complete rewrite, that'll only work for Word 2013 and later.

[dkager]

It's not specific to braille as such, but it'll be a lot worse with braille than without because braille causes more queries to Word. We might be able to tighten this up with some caching, but there are always going to be performance problems here because of the way we have to get information from Word.

Any ideas on what in particular could be cached? Are there any other solutions, such as sacrificing a bit of information for greater performance? For example, I notice that in Outlook 2016 the performance hit increases substantially as your e-mail grows larger. Even on last year's laptops working with Word/Outlook is very laggy with braille enabled.

[LeonarddeR]

I wonder whether braille.TextInfoRegion.update could be of negative impact here.

A major drawback of that code is that it fetches textInfo text with fields in multiple runs. First, it gets the fields before the cursor/selection, then the selection/cursor itself, and then the fields for the text after the cursor/selection. This means that in the best case, getTextWithFields is called twice. This means that NVDA calls to word twice, gets several infos (including paragraph info twice), and even the info that isn't shown in braille at all.

I think that there are some ways this can be improved:

1. A quick work around would be a filter function in the braille module that removes all the items from the formatConfig dictionary that braille ignores anyway, before passing it to getTextWithFields. This shouldn't be that much work and will likely improve things in a major way for Word with braille enabled.
2. A separate format/object presentation config for braille. This has been a desire for years and something that would be good for NV Access to consider as a major item on their roadmap.
3. have selectionStart / selectionEnd / cursorPosition format fields returned by getTextWithFields, so braille can call getTextWithFields only once. This would require a major rewrite of a lot of textInfo implementations, though.

Any other ideas? @jcsteh: what do you think about these?

[LeonarddeR]

@leonardder commented on 4 Jun 2019, 20:11 CEST:

1. A quick work around would be a filter function in the braille module that removes all the items from the formatConfig dictionary that braille ignores anyway, before passing it to getTextWithFields. This shouldn't be that much work and will likely improve things in a major way for Word with braille enabled.

Here is a prototype try build.

Cc @adriani90 @lukaszgo1 @bramd @DrSooom

[jcsteh]

All of these ideas have merit. I don't think we've considered the filtering idea before (and that could be a nice quick win), but we've definitely discussed the other two.

With regard to the fields including selection start/end and caret, this would require significant work/rewrites, as you say. However, it may be really tricky for some implementations. For offset based implementations, it's not so hard because you can map the offset of the caret, etc. directly to an offset in the string. For implementations that aren't offset based, though, it gets really messy: the underlying positions are opaque, and even if there is some call to get the number of characters between two points, you can't assume that a character and an offset are the same thing. For those cases, you're probably going to end up having to internally fetch the fields in three chunks anyway, although you might be able to make some optimisations because you know you're going to do that.

[lukaszgo1]

I am using braille only very occasionally when working with LaTeX documents, so I cannot comment here unfortunatelly.

[Adriani90]

@zstanecic are you still having this issue with NVDA 2023.1 RC1 and last build versions of Microsoft Word?

[ABuffEr]

Hi, there being some discussion above, I report here that, recently, an user on Italian community had a great improvement in performance simple disabling "Read by paragraph" in Braille settings.

[Adriani90]

@ABuffEr that's interesting. Just a short note that this setting is actually disabled by default.

@leonardder sorry I've totally missed your cc here, I had some other projects during last years so I could test your prototype now. Could you please rebase it on the last alpha version of NVDA?

[Adriani90]

Does anyone see further performance issues with a braille display in NVDA 2023.2? Now my braille display is unfortunately broken, but tested some weeks ago and noticed a significant improvement. cc: @aaclause

[AAClause]

I've had fewer opportunities to use Word recently, but I just tried it with the 2021 version (16.0.16731.20234) and with UIA enabled, the performance seems good to me in several hundred-page documents. NVDA version: alpha-29194,ec914517

[Adriani90]

@aaclause what about performance when UIA is disabled? Note UIA introduces many other bugs when using Microsoft Word, so many users do not really enable it in practice.

[Adriani90]

@burmancomp could you provide an update on NVDA performance in MS Word with UIA disabled in NVDA last alpha / advanced settings? Is this issue reproducible for you with paragraph reading enabled and / or disabled in braille settings?

[burmancomp]

With quick testing:

If I use UIA always (but note that my system is w10 2022h2), braille scrolls rapidly. When using other UIA settings scrolling is slow. If I however enable "read by paragraph" when UIA is not "always", scrolling feels faster (I mean text seems to change on braille line faster when pressing and holding down braille next line button).