Bugzilla – Bug 1436
File based preferences are slow to retrieve.
Last modified: 2018-08-20 11:46:15 UTC
Opening preferences has a noticeable delay (seconds), far higher than one would expect based on what it is doing. Also, anecdotally, direct use of preferences in Audacity code leads to performance issues. This points to the underlying wxFileConfig preference mechanism being slow.
DEVEL - FIX MADE https://github.com/audacity/audacity/commit/8afeed5f787d647f36662d5d1cf1ba0d6f717492 This makes sorting in the preferences dialog faster. My guess/expectation that preference retrieval accounted for most of the delay seems to have been wrong as the faster sorting makes a dramatic difference. It now can take about 2s to open the dialog, which does not feel sluggish. I tested that the sorting is still sorting correctly. I also used code analysis to confirm that using a different language would not throw out the sorting by continuing to sort based on an old/previous language. I tested on Windows only. Robert has reported slow opening of preferences with Screen Readers. If that continues after this DEVEL-FIXED, then there are other causes and updated steps are probably needed.
Further work to speed it up with this commit: https://github.com/audacity/audacity/commit/597ddbfa52f9b1cb685f4bb04d582a2f29b2cda7 This change does the sorting once not three times on creation, and also creates trees with the items open, rather than closed and then opening as a separate step. Should be about 3x faster in creating the keyboard prefs panel which was the one taking most of the time.
Added David and Robert to Cc list. Testing Debug builds before and after these commits (Win 10, HDD, 2.4 GHz, 6 GB RAM), Audacity takes a reliable 1 to 2 seconds to open Preferences in English language or not, and NVDA adds 1 second to that. So no difference here between the commits. Note I am not running special VI scripts. I think Robert or David are better placed to test that. Do the steps imply that testers should be running Audacity inside Visual Studio, Xcode or some other IDE? I was not doing that.
Testing on Windows 10 (Release) after the two commits with keyboard as the focused category and tree view there as well. Narrator: Speaks fine (Verbosity 0), "Preferences: Keyboard Dialog | keyboard 14 of 16 selected" However, it opens extremely slow, initially with about 5 seconds. I then navigated to the keyboard tree, collapsed all menus and clicked OK. Closing takes also a while (2 to 3 seconds). Reopening Preferences can take up to 30 seconds (!). JAWS 18: Similar output as Narrator, starts in about 1 - 2 seconds. WindowEyes 9.54: Similar Output and start time. The keyboard tree is not useable ("Selected Tree view" instead of the actual item). However, "Big Mama" has not only chosen to swallow ZoomText without chewing but WindowEyes as well: http://www.gwmicro.com/window-eyes/migrate/ In other words, official support has stopped. NVDA master-14057,a1350576: Start time is much better (1 to 2 seconds) and seems seamless depending on chosen verbosity. Does not read "Preferences: Keyboard" unless you move to another application and back. Instead, it reads "Tree Control, Tree view | Devices not selected, 1 of 16, Level 0 | Keyboard 14 of 16 Level 0". When moving to the keyboard tree, "Bindings" is focused and read (instead of focus on "File (expanded)". I suggest that "Tree Control" will be changed to "Category". That "Devices" is read may be a NVDA bug (it happens also in the explorer tree). In summary, all screen readers perform better except Narrator.
Robert, My copy of Narrator does not have a verbosity setting. Preferences consistently opens within 2 seconds with Narrator running. Could you try after a reboot, and then ONLY using narrator, and see how it behaves? I am guessing the different screen readers could be fighting each other. Devices is the first item in the tree. Buttons such as "Clear" are read out as "Cl & ear" which I think we can fix easily.
Hi James After rebooting, Narrator works as you describe the first time but then it slows down on successively opening preferences. If you're on Win 10, the contextual verbosity is Caps+Alt+/ (forward slash). Another possibly useful keystroke: Shift+Caps+F12 which enables developer mode (showing only items with focus, rest of display is masked). I've also tried accevent.exe and accexplorer.exe which are included in the Windows 10 SDK. Also available here: https://github.com/blackrosezy/gui-inspect-tool but perhaps a bit outdated. Yes, devices is the first item and NVDA reads it accidentally (if it isn't the last category used). Note also the comment about "Tree Control" -> "Category". It's counterpart for the keyboard tree is "Bindings" which is fine. NVDA has natively a mini-add-on that prevents the '&' from being read within button labels, otherwise it would behave like Narrator.
Steps seem unrelated to the comments #4 onwards and don't explain how to test on the three platforms despite my asking this in comment #3. It looks then like this should be RESOLVED WORKSFORME given James/Robert see an improvement, and a new Narrator bug created as follow up to this by James or Robert. Accessibility is broken to greater or lesser degree on Mac and Linux, so immediate versus two seconds to open preferences on a developer SSD seems neither here nor there in that context.
I agree with Gale's comment #7 Just for Information: My 'fast PC' has HDD, not SSD. I was running within MS Studio. Further points: With Narrator I see memory leaks, and I see no leaks when not using it. Robert reports JAWS and NVDA opening fast. I see Narrator opening fast, so cannot progress 'slow opening with Narrator'. The original guess that file-based preferences was very slow was wrong. They are slow compared to reading a variable, so should be avoided in inner loops, we've been bitten by that in envelope drawing code, but in preferences dialog they are OK. I think the residuals Robert sees in preferences are best in a new accessibility specific bug. Possibly we should use a wiki page as we did for http://wiki.audacityteam.org/wiki/Bugs_In_DA_Integration Closing 'WORKSFORME'
FWIW I tried a debug build of HEAD running from Visual Studio on Windows 10 with Narrator running (no other accessibility aids or screen readers were running). I did not see a slow down on returning to Preferences at any of the Narrator verbosity settings.
Closing the bug is fine for me. Narrator hasn't a logging facility so it is fruitless to pursuit this issue for my machine further. What happens on other platforms? The "treeCtrl" bug should now be solved as well. I will probably create a new bug for the keyboard tree issue--wrong focus, WindowEyes unable to speak the selected item.
