VS Code is no longer as sluggish when arrowing up and down through large files #17051
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… in VS code, and is not correctly implemented in Chromium anyway.
WalkthroughThe changes introduce enhancements to NVDA's integration with Visual Studio Code, focusing on improving performance during navigation in large files. A new class structure is implemented to optimize text handling, specifically addressing sluggishness when using arrow keys in focus mode. The modifications ensure existing features remain functional while providing a more responsive experience for users. Changes
Assessment against linked issues
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add Documentation and Community
|
SaschaCowley
approved these changes
Aug 26, 2024
CyrilleB79
reviewed
Aug 26, 2024
LeonarddeR
reviewed
Aug 26, 2024
seanbudd
added
the
conceptApproved
5 tasks
seanbudd
pushed a commit
that referenced
this pull request
Aug 28, 2024
… yet implement what we need, and it is costly for no gain. (#17067) More broadly fixes #17039 Summary of the issue: In PR #16745, code was added to detect the caret at end of lines in Mozilla-compatible edit areas, so as to not report the next line when on the final insertion point of the line before. Although this works great in Firefox and other Gecko-based apps, it does not work at all in Chromium due to Chromium not correctly implementing IAccessibleText::textAtOffset with IA2_OFFSET_CARET. More importantly, this is a very costly check in VS code, which has a noticeable performance hit when arrowing up and down large files (issue #17039), for no gain. PR #17051 successfully fixed the performance hit in VS code by disabling caret at end of line detection just for VS Code. But it was pointed out that there are several VS Code variants including VS Code.dev which require this also. Description of user facing changes NVDA is no longer as sluggish when arrowing up and down large fles in VS code and otherChromium-based applications. Description of development approach Remoe the VSCodeditor and VSCodeEditorTextInfo classes from the VS ode appModule introduced in pr VS Code is no longer as sluggish when arrowing up and down through large files #17051. Add Editor and EditorTextInfo classes to NVDAObjects.IAccessible.chromium which are used in Chromium where ever NVDAObject.IAccessible.ia2Web.Editor is used. These classes disable caret at end of line detection for any chromium edit area.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Link to issue number:
Fixes #17039
Summary of the issue:
With the introduction of pr #16745 which added better reporting of the caret at when at the end of a line, VS Code became quite slow when arrowing up and down through particular large files.
IAccessibleText::textAtOffsetwithIA2_OFFSET_CARETis very costly in VS Code, and Chromium does not actually implement this correctly yet anyway.Description of user facing changes
NVDA is less sluggish when arrowing up and down through large files in VS Code.
Description of development approach
VS code appModule: provide a new
VsCodeEditorTextInfowhich disables end-of-line caret detection by returning False in_IsCaretAtEndOfLine.Testing strategy:
Opened source/NVDAObjects/IAccessible/init.py in VS Code, and moved to line 1491, and arrowed down several line. Confirmed that the sluggishness was gone.
Known issues with pull request:
None known.
Code Review Checklist:
Summary by CodeRabbit
New Features
Bug Fixes