text style navigation: NVDA hangs for at least 1-2.5 seconds when using MS Word with UIA disabled #16458
Comments
|
cc: @mltony Is it really important to have the new line characters and the tab characters part of same style or different style navigation? I think this might have an influence on the performance of this feature. In the log many tab and new line charachters are registered. Also this could be related to #16408. |
|
One further thing that impacts the performance of NVDA in this regard is the fact that NVDA tries to construct a speech uterance to speak at once the whole region where the same style or different style text is found. If the region contains a lot of text, NVDA will need longer time until it begins speaking. |
|
Similar to #16459 I can't seem to reproduce this.
Not sure I understand this question. Style nav takes any text style into account, even when style is applied to tabs and newlines. Actually I'm not sure how newlines are treadted in MSWord, I would suspect it must be impossible to set font size or color of a new line character. But I might be wrong.
In theory that should be possible, but I am reluctant to invest into this feature, because its not that important as assessed by nvaccess and there is still a chance it'll be rolled back because some of the issues with TextInfo implementations it uncovered might be difficult to fix. |
seanbudd
added
app/microsoft-office
p3
That's exactly what I tried to challenge here. Is this at all needed? What is the use case to check styles on tab characters and newlines?
Where has that been assessed by NV Access? Here is my use case:
We need confirmation from @seanbudd and @michaelDCurran and @gerald-hartig on this, but in my view this feature does not have assigned gestures by default and is a really good test environment for textInfo improvements in certain cases. We have lots of situations where features are not working perfectly in NVDA. |
|
Because it's simpler this way. Did we see any adverse effects of checking style of tabs and newlines? |
|
Somehow yes. Users land often on lines which contain only tab or space characters, or on new empty formated lines. I think this is not helpful, people expect to find text or symbols, but not empty lines. Also this quite probably has adverse performance effects, especialy when using empty table cells or lots of tab and space characters. See also the outlook issue where NVDA tries to find it via textInfo.I suggest to test this feature at least without looking for tab, space or newline characters.I would be happy to provide results if you generate a coresponding try build. Von meinem iPhone gesendetAm 30.04.2024 um 21:54 schrieb mltony ***@***.***>:
Because it's simpler this way. Did we see any adverse effects of checking style of tabs and newlines?
As for low importance, Sean marked #16000 as P5 and also perhaps in some other issue he suggested not to assign any default keystrokes to style navigation.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
Here is a concrete example document. A paragrpah has 5.561 characters, NVDA freezes for at least 5 seconds until it starts speaking. This is totally inefficient because in this case NVDA should not read the whole same style text. It seems NVDA needs approx. 1 second per thousant characters, at least on my machine which is an Asus Rog Strix with an Intel processor I12900HK 5 GHZ, grafic card NVIDIA GTX 3070TI with 8 gb dedicated grafic storage, 32 gB DDR. This same sty / different style feature definitely needs optimization in this regard. |
|
I found a severe freeze of at least 10 seconds also when using UIA in MS Word with style navigation, see this error ant the attached document. In general, using style navigation in the attached document fails alot and is sluggish. |
) Closes #16459 Closes #16408 Closes #16458 Closes #16405 Summary of the issue: We have discovered multiple problemds with non-UIA textInfo implementation in MS Word. Some examples are #16527, #16459, #16458. Also TextInfo implenetation in Outlook has proven to be too slow for style navigation. Therefore disabling both. Description of user facing changes "Not supported in this document" message is spoken. Description of development approach Raising an error when Outlook or non-UIA Word is detected.
Steps to reproduce:
Actual behavior:
NVDA hangs and the navigation is not very efficient. The longer the document, the longer the freeze. This is written in the log:
Expected behavior:
No freeze while navigating.
NVDA logs, crash dumps and other attachments:
n/a
System configuration
NVDA installed/portable/running from source:
Installed
NVDA version:
alpha-31645,bf96860d (2024.2.0.31645)
Windows version:
Windows 11 23 H2
Name and version of other software in use when reproducing the issue:
MS Office Word 365 MSO (Version 2403 Build 16.0.17425.20176) 64 Bit
Other information about your system:
Asus ROG strix 32 GB DDR ram, Intel I12900HK 5 ghz, NVIDIA GTX 3070TI grafic card with 8 gb dedicated storage.
Other questions
Does the issue still occur after restarting your computer?
yes
Have you tried any other versions of NVDA? If so, please report their behaviors.
n/a
If NVDA add-ons are disabled, is your problem still occurring?
no add-ons in use
Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?
yes
The text was updated successfully, but these errors were encountered: