Okay. I finally had enough of git pull and the like making my entire system unusable thanks to UIA event flooding that I took the plunge and switched to Windows Terminal with UIA notification events. I was having trouble with Windows Terminal previously, but that was with diffing. Notification events seem to be working fairly well so far. Let's see how it goes.
One concern I do have is that NVDA necessarily registers for notification events globally, which means that a notification event flood from a background terminal is going to impact performance. Hopefully terminal manages notification events better than it does text events. We shall see.
=> More informations about this toot | More toots from jcsteh@aus.social
Well that didn't take long. Spamming the console still makes the system pretty much unusable if the console is focused when it happens. But interestingly, if the spam starts in the background or I can manage to alt+tab out (which is very difficult because it's so slow), it seems to behave. That either means that Terminal is smart enough not to send notification events while in the background (but then I'm not sure why NVDA has explicit code to ignore those) or that the poor performance is entirely due to NVDA struggling to process the notification events (but ignoring them is okay).
=> More informations about this toot | More toots from jcsteh@aus.social
Nope, Terminal notification events are causing a bunch of stuff that isn't actually changing (just scrolling) to be read, so I'm back to conhost. There are no good options. I hate this so much.
=> More informations about this toot | More toots from jcsteh@aus.social
Ah. My issues with UIA notification events reading text they shouldn't are almost certainly due to me using tmux. I guess it redraws the screen when text overflows or something? Or maybe that's a bug in Windows Terminal's UIA implementation.
=> More informations about this toot | More toots from jcsteh@aus.social
Terminal doesn't fire UIA notification events when in the background, which is great. It turns out that the thing that's really slowing down NVDA's handling of those on my system isn't speech processing or anything like that. It's... logging! I tend to have my log level set to debug, which logs a lot. I never realised just how much that logging could slow things down when there's this much data.
Interestingly, if I set my speech mode to beeps, that's also very laggy. I guess it's expensive to continually generate and play the tone, even if we stop it very quickly.
=> More informations about this toot | More toots from jcsteh@aus.social
@jcsteh This reminds me that at some point I want to experiment with a custom protocol between the AccessKit Windows backend and ATs like NVDA (I'd almost certainly start with an implementation in an NVDA add-on), then implement AccessKit support in one of the Rust terminals, like wezterm. The custom protocol would push a tree update once per frame. Not sure if I'd use a named pipe or some other transport.
=> More informations about this toot | More toots from matt@toot.cafe
@jcsteh Try set -g terminal-overrides 'xterm*:indn@' in .tmux.conf and see if that improves things.
=> More informations about this toot | More toots from tspivey@dragonscave.space
@tspivey Heh, I was just fiddling with that, as discovered in various tmux GitHub issues. I don't really understand what it does though. I know indn is related to scrolling, but how does it prevent Terminal from misbehaving in this case?
Also, any idea why tmux seems to redraw the entire screen after an alert message (like "Can't find window: 1")disappears? I haven't found a way to disable that. Disabling indn doesn't fix it.
=> More informations about this toot | More toots from jcsteh@aus.social
@jcsteh When I run tmux, seq 1 100, cat, then type test, tmux sends "\r\33[2S\33[Atest\33[K\r\n\33[K" to the terminal after I press enter.
indn@ disables the \33[2S part of the sequence, so now it has to send something else, in my case "\33[30;120H\n\n\33[29;1Htest\33[K\r\n\33[K".
I guess whatever's generating the notifications for Windows Terminal doesn't like scrolling with escape sequences, but the absolute positioning works fine.
I haven't found a fix for redrawing after the messages either, but it happens so infrequently I can just ignore it.
Another problem is that text gets split up sometimes, for example paste in It’s and press enter. Notice the unicode apostrophe. tmux does weird things with cursor movement there, and nothing handles that well. Most of my usage is with tdsr outputting to NVDA, and I don't need to disable indn. It just reads the bytes as they come in.
Windows Terminal fails the basics, I can't press Alt+letter without NVDA re-reading the focus.
=> More informations about this toot | More toots from tspivey@dragonscave.space
@jcsteh Screen does something like this for me too when I exit a screen, and in fact due to scrollback it causes the entire scrollback buffer in WT to be read out when that happens. Which can hit the speech large chunk delay.
=> More informations about this toot | More toots from x0@dragonscave.space
@x0 Is this with NVDA set to use UIA notification events? I'm not surprised by it reading a whole bunch of text, but I've discovered it shouldn't delay too badly if you're using UIA notifications, Windows Terminal and have NVDA log level set to info.
=> More informations about this toot | More toots from jcsteh@aus.social
@jcsteh No diffing, which makes sense I suppose, it un-paints. I didn't think using UIA notification events was stable yet for small updates, especially with progress bars and the like.
=> More informations about this toot | More toots from x0@dragonscave.space
@x0 It definitely has some rough edges. See other posts and replies from me recently regarding tmux settings necessary to make Windows Terminal's UIA notifications behave correctly when text scrolls off the screen in tmux.
=> More informations about this toot | More toots from jcsteh@aus.social
@jcsteh I had that issue too, does it do the same thing if you do NVDA+shift+z on the terminal before pressing return on the command? I never tested it but it could be the voice synth getting really backed up. I’d try it now but my work computer doesn’t read ANYTHING in command prompts of all sorts because of corporate malware…
=> More informations about this toot | More toots from chinakow@mas.to
@chinakow Yeah, I suspect it might actually be NVDA's speech processing code getting backed up. I'll experiment with that at some point if I can be bothered, as it's probably not too ridiculous to fix that.
=> More informations about this toot | More toots from jcsteh@aus.social
@jcsteh Okay, maybe this is a stupid suggestion but…why not pregenerate the required tone for the required duration when NVDA starts? Then you don't have to generate it over and over.
=> More informations about this toot | More toots from jaybird110127@dragonscave.space
@jaybird110127 That is indeed one option I thought of to optimise that, yes. Whether or not that is the actual bottleneck is yet to be determined.
=> More informations about this toot | More toots from jcsteh@aus.social
@jcsteh A year or two ago I actually came up with a weird way to not have to generate tones at all. When speech mode is set to beeps, rather than playing a specific tone, just output the actual text to be spoken, not as speech but in its raw binary form, to the audio device. This would be most useful with long text dumps. For something like single characters, a single byte probably isn't going to convert to enough sound to make a noticeable noise.
=> More informations about this toot | More toots from jaybird110127@dragonscave.space
@jaybird110127 I follow. As you say, though, it's problematic for smaller chunks, which I'd say is fairly common for a screen reader.
=> More informations about this toot | More toots from jcsteh@aus.social
@jcsteh If, by chance, you're sitting there going "Huh? What in the world is this kid talking about?" Start any audio editor that lets you open headerless files as raw PCM. Open a file that is, in fact, not an audio file at all. Specify the sample rate, bit depth, number of channels, etc. as you like. If you then play it, you'll hear some random noise. Text files, logs, etc. tend to generate the coolest noises. Anything compressed is going to sound like white noise, in other words, a loud hiss covering the entire frequency spectrum.
=> More informations about this toot | More toots from jaybird110127@dragonscave.space This content has been proxied by September (3851b).Proxy Information
text/gemini