NVDA is slow with Juce

[Lo-lo78]

Steps to reproduce:

with plugins with a lot of information with reaper NVDA is slow. If we add Surge XT into the fx chain it takes a long time to get the speech to speak. Surge is a synth. With sonobus it is a little faster but the problem remains.

Actual behavior:

Expected behavior:

NVDA logs, crash dumps and other attachments:

There are no bugs or crashes. it's just a little slow.

System configuration

NVDA installed/portable/running from source:

NVDA version:

NVDA: 2022.2.2 installer

Windows version:

Windows 10 21H1 (x64) build 19043.1889

Name and version of other software in use when reproducing the issue:

Reaper 6.66 plugin synth Surge XT

Other information about your system:

Other questions

Does the issue still occur after restarting your computer?

yeas.

Have you tried any other versions of NVDA? If so, please report their behaviors.

The problem remains the same

If NVDA add-ons are disabled, is your problem still occurring?

yeas

Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

yeas

[baconpaul]

Hi! I’m a dev on surge if you need help

you can download the tool at https://surge-synthesizer.GitHub.io

[lukaszgo1]

Is the slow down reduced when setting "Registration for UI Automation events and property changes:" in advanced panel to "Selectively"?

[Lo-lo78]

@lukaszgo1 No. The problem remains.

[lukaszgo1]

Have you restarted NVDA after changing this setting - the change is not effective otherwise?

[Lo-lo78]

Yeas. I restarted NVDA and it seems faster. It's not perfect but it's better. You can actually work with less frustration. 👍

[baconpaul]

Curious what that option does?

Surge does send structure-level rebuilds with some frequency and i was wondering if perhaps that triggers something quadratic or some such inside your code when we invalidate 400 components at once.

Thanks!

[Lo-lo78]

If NVAccess wants to interact with the Surge team, the contacts are: https://github.com/surge-synthesizer/surge https://discord.com/invite/spGANHw They are very kind. NVAccess could suggest more advanced accessibility ideas.

[seanbudd]

This sounds related to #11002

[feerrenrut]

when we invalidate 400 components at once.

What I suspect happens (investigation required for confirmation): for each of these events NVDA has to facilitate a cross process UIA call to fetch details about the change (these must be scheduled by windows, and each causes significant delay, in the order of milliseconds per fetch).

Some potential solutions to this:

• Filtering out events NVDA doesn't use/need.
• Using UIA remote, a mechanism to batch many calls together into a single cross process fetch. Ideally after receiving a single top-level event.

[baconpaul]

If you want to try it out you can download surge from https://surge-synthesizer.github.io/ and run either the standalone or the VST3 in a daw (if you have reaper from https://reaper.fm/)

Actions which will force a rebuild include selecting a different LFO or Oscillator type. Here is how you do it in the sighted UI and in the screen reader UI

and in the spoken UI that element will be a button in the oscillator group with a name like "Classic, Oscillator Type" which you can navigate to, press using a press action, and then choose a different type from the menu.

[ultrasound1372]

The biggest slowdowns for me are when a menu is dismissed due to a selection or escape. NVDA takes a fair bit of time to actually give focus to the window again. I'm afraid to enable UIA selective registration as I'm concerned it might break OSARA.

[ironcross32]

Indeed, one surefire way to see this slowdown in action is to open Surge within Reaper, bring up the modulation list with Alt+M, tab to the select source button, and select a source from within the submenus. When the menus are dismissed, there is about a 2 second period in which NVDA cannot be made to speak.

[pitermach]

Just did some testing on my end by doing the following:

• In Reaper with Osara installed, add surge to a track, bring focus into the plugin with F6. You can already see the problem here because NVDA takes about a second on my system to speak, though from comments here it can take even longer on other systems
• Tab around the interface which should be instant.
• Bring up a context menu on any control with Shift+F10, arrow around the menu, then press escape to close and tab to move to a different control (there's an unrelated bug with Juce here which requires you to move the focus before Windows becomes aware the menu is gone which is why the extra tab is required). This once again causes the performance problems to become apparent and I get the previously mentioned second of delay
• Now I repeat the same steps with opening and closing a menu and tabbing but in the surge standalone application. Here there's absolutely no delay.

The main difference between the 2 is that Reaper nests the plugin's controls inside a property page, which first includes a couple of buttons from reaper itself, followed by the plugin's controls, while in the standalone app all the controls appear in the window element. Perhaps the property page is the factor here?

Selective UIA registration doesn't affect this in any way. I still get the same amount of lag with it on or off.

[ironcross32]

One thing that can be done to ameliorate the condition is to find Surge in the FX add dialog before any instance of it exists on any track, then perform a right-click or use the applications key. From there, find the submenu, "Run as", and within that, select, "Dedicated process". This setting is remembered for any future instances. Then, load Surge XT plugin onto a track. This causes there to be a separate window for Surge's UI. F6 is not needed to focus it, simply tab between it and Reaper.

Two things now happen. There is a noticeable amount of latency that is gained when tabbing through the interface. But, as it pertains to the issue at hand, repeating the test from my previous comment, NVDA can be made to speak immediately after the source or target menus are dismissed from within Surge's Mod list.

I have no clue how causing the plugin to load with its own process rather than from within Reaper itself causes these things, but they should theoretically be reproduceable by anyone.

[ultrasound1372]

Something about Reaper's FX dialog makes NVDA lag inn general, almost no matter what VST is involved. If you have SIBIAC enabled, disable it. It's probes introduce significant lag and error flooding on plug-ins it doesn't recognize.

[pitermach]

Oh yeah, I should probably amend my last comment with the fact I didn't have any addons like sibiac running, just braille extender and a few speech synthesizers. Though I did try running with them disabled and this also made no difference.

[Lo-lo78]

Hi everyone! I tried in NVDA advanced settings but even with alpha versions nothing changed with Juce. Can a solution be found in the future when there are so many events in NVDA? NVDA With Juce when there are many events it becomes extremely slow. With Narrator there is no latency with Juce. Greetings.

[Lo-lo78]

The most important problem is when Surge exits the context menu. NVDA hangs for two seconds consuming CPU. The bigger the Reaper project, the slower NVDA gets with Surge. In these cases the CPU suffers a lot. Thank you!

[Adriani90]

cc: @jcsteh, @leonardder, @Robert-J-H if I remember correctly you are quite experienced with reaper, maybe there is a possible fix related to @leonardder 's code for Registration for UI Automation events.

[jcsteh]

I haven't looked into this, but it likely occurs because REAPER embeds plugins in a property page and NVDA walks property pages trying to derive a caption/description for the property page (since property pages are usually used in dialogs). If there are a lot of children inside the property page (and potentially descendants, since NVDA will descend inside children with certain roles such as grouping), that calculation is going to take a long time and probably produce nothing useful. That is going to happen every time the window comes to the foreground, which is consistent with the user reports that this occurs when dismissing menus, switching windows, etc.

[jcsteh]

For those experiencing this, does turning off "Report object descriptions" in NVDA Settings -> Preferences -> Object presentation help?

[ironcross32]

Agreed with @Lo-lo78

Turning this setting off does nothing @jcsteh

I believe it's the sheer number of controls that Surge has that plays into this. I don't notice it with plugins like Pianoteq.

[ultrasound1372]

It's likely related to the fact that these controls, via Juce, generate UIA events, possibly multiple for each control as they repaint. This would cause a sudden dramatic spike of events which selective registration wouldn't help, as NVDA actually does need to know about these controls. Perhaps with the new rc build we can debug exactly how dense this is?

[Lo-lo78]

@feerrenrut @jcsteh @pitermach @seanbudd @lukaszgo1 It doesn't change with the NVDA settings that James suggested. What slows down a lot with Surge is exiting the context menu and opening the plugin. I don't know with Jaws but with Narrator it's very fast. In the past NVDA had problems with very large lists but this has been fixed. Maybe there is a system that can make NVDA faster with Juce. But I'm just a user and I don't know what hurdles there are in development. Greetings!

[jcsteh]

I'm not convinced this isn't related to the property page thing I mentioned, despite that setting not changing anything. The fact that this lag occurs when you exit the context menu is super suspicious. That's less likely to be events and more likely to be related to something happening on focus. I now suspect NVDA is still doing that calculation even when that setting is off.

Can people experiencing this please do the following:

1. Open the NVDA Python Console with NVDA+control+z.
2. Paste this line, then press enter: import NVDAObjects.behaviors; NVDAObjects.behaviors.Dialog.description = None
3. Now test to see if you can reproduce the lag.

Note that this will break dialog descriptions across the board, but you can restore things by restarting NVDA.

[ironcross32]

@jcsteh Immediately better after doing as you laid out.

[jcsteh]

Okay. I'm trying to figure out some way to hack around this in OSARA, since those things ideally shouldn't be exposed as property pages in the first place. It's... harder than I expected.

That said, this dialog description code in NVDA has been a problem on a few occasions and I really think it might need to be re-thought. It's a potential performance cliff in any complex dialog or property page.

[jcsteh]

I just submitted a hacky pull request to OSARA to try to address this. It should complete automatic builds in a few minutes. I'd encourage anyone experiencing this to give that a try and comment there on your findings.

[Lo-lo78]

@jcsteh It works with the code string: import NVDAObjects.behaviors; NVDAObjects.behaviors.Dialog.description = None Now the plugin is much more manageable both in opening and in navigation. 👍

[ultrasound1372]

Apologize, the previous two comments were directed at the wrong thread.

[jcsteh]

I've addressed this in OSARA, so I'm closing this. However, as I noted above, I think NVDAObjects.behaviors.Dialog.getDialogText needs to be re-thought for better performance. This isn't the first time it has caused problems and it won't be the last.