Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Optional logging of time since input when speaking. #9167
Link to issue number:
Summary of the issue:
When working on performance improvements or identifying performance regressions, it is useful to be able to measure perceived responsiveness. A starting point is to measure the time between input from the user (e.g. a key press) and when text is spoken. We already log times, so it's already possible to do this by subtracting the input log time from the speech log time, but that's fairly tedious at scale, especially given that there can be several log entries between the two relevant entries, the times are logged as full times (not just seconds) and the log times are at the end of the line. We want to make measuring perceived performance as simple as possible.
Description of how this pull request fixes the issue:
This PR introduces optional logging of time since input when text is sent to to be spoken. It can be enabled in the debugLog section of the config using the timeSinceInput setting. It is logged at level IO if this setting is enabled.
Note that the last input time is not reset after the time since input is logged. That is, if a key press generates two spoken messages, the second will show the time since the last key press (>= the time since input for the first message). This can be useful if the first message isn't the primary information the user cares about or if, for example, speak command keys is enabled (in which case the first message will be the key being spoken).
Tested cursoring through the NVDA menu with the debugLog -> timeSinceInput setting set to False. Verified that time since input was not logged.
With the setting enabled, tested cursoring through the NVDA menu, using object navigation in Gmail, pressing control+o to bring up the Open dialog in Notepad, moving by line and character in Notepad. Verified that the time since input logged seemed proportional to my perception of performance in these cases.
Known issues with pull request:
Change log entry:
Changes for Developers: