GNOME Bugzilla – Bug 754971
at-spi feedback on arrow keypress is slow
Last modified: 2021-06-10 15:05:37 UTC
Hello, The cursor routing feature of brltty in vte is very slow, typically a few dozen ms per character movement. Cursor routing means that the braille user pressed a button above a braille cell to request the cursor to come there. Brltty will then simulate appropriate arrow keys to bring the cursor there (left and right arrows, typically) Tracing shows that the delay is between brltty emitting the arrow keyboardevent and the corresponding caret event coming back. AIUI, VTE avoids emitting signals too fast, so as to try to coalesce effects before providing feedback (what makes me think this is the reading of process_timeout, which apparently only gets called after DISPLAY_TIMEOUT ms elapsed). I guess this is the culprit for the delay. Usually a few dozen ms delay between the user pressing an arrow key and the result being display is considered interactive enough, but here we do not want this delay: the goal is for brltty to get the feedback as quickly as possible so as to continue simulating arrow keys to route the cursor to the target. The current delay makes it very inconvenient (one has to wait for a few seconds). I'm not sure how to deal with this. The issue is that the relation between the keyboard event and the resulting caret movement is not immediate, since that goes through the application. Perhaps when VTE gets a keyboard event, it should reduce the delay just once, i.e. the following scenario: - waiting for key event or application output - getting a key event - thus setting display timeout to 1ms - writing the key event to the application - waiting for key event or application output - getting the application output, which is a caret move - thus scheduling a display update within 1ms - waiting for key event or application output or display update timeout - timing out after 1ms - thus showing the caret move and emitting the at-spi caret update - and setting back the display timeout to 10ms - waiting for key event or application output That way we should be able to make VTE more interactive when the user (or brltty) is typing, while not making it less efficient when he is not. Samuel
The choice of 1ms is a bit arbitrary. The idea is that it should be long enough for the application to be able to make all of its output corresponding to the move (which may include e.g. the update of a cursor position in the status bar of an editor), which being as small as possible for best interactivity.
The whole idea behind the DISPLAY_TIMEOUT stuff is to display updates in larger batches (potentially skipping tons of intermediate data). Even for a11y, it might make sense to call the proper callbacks less frequently, with bigger data chunks each time. Except for the use case you mentioned. Bug 744774 might be relevant. I wasn't brave enough to touch that code yet, and having to care about a11y won't make it any easier, although it seems to me that both feature requests want to modify the algorithm basically in the same direction :)
Ok, so I guessed it all right :) Samuel
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/2225.