Optimize rendering performance by scheduling DOM updates at the next animation frame in NativeEditContext and TextAreaEditContext#285906
Conversation
…animation frame in NativeEditContext and TextAreaEditContext
There was a problem hiding this comment.
Pull request overview
This PR optimizes rendering performance by deferring expensive DOM updates to the next animation frame in NativeEditContext and TextAreaEditContext, reducing reflow pressure during chat view scrolling. The changes prevent layout thrashing by scheduling DOM measurements and updates asynchronously.
- Introduces animation frame scheduling to defer DOM updates in edit context rendering
- Adds proper cleanup in dispose methods to prevent memory leaks
- Maintains the same public API while optimizing internal rendering behavior
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| src/vs/editor/browser/controller/editContext/textArea/textAreaEditContext.ts | Adds _scheduleRender() method to defer _render() execution to next animation frame, with proper disposal handling |
| src/vs/editor/browser/controller/editContext/native/nativeEditContext.ts | Refactors _updateSelectionAndControlBoundsAfterRender() to schedule _applySelectionAndControlBounds() at next animation frame, with proper cleanup |
| private _targetWindowId: number = -1; | ||
| private _scrollTop: number = 0; | ||
| private _scrollLeft: number = 0; | ||
| private _selectionAndControlBoundsUpdateDisposable: IDisposable | undefined; |
There was a problem hiding this comment.
The field _selectionAndControlBoundsUpdateDisposable uses undefined as the sentinel value, while the analogous field _scheduledRender in TextAreaEditContext uses null. For consistency across these related implementations, consider using the same sentinel value (either null or undefined) in both files.
| private _selectionAndControlBoundsUpdateDisposable: IDisposable | undefined; | |
| private _selectionAndControlBoundsUpdateDisposable: IDisposable | null = null; |
|
The render call for all ViewParts in the editor should already happen during animation frames, unless someone uses editor APIs that would cause forced synchronous rendering. I think I would like to be able to replay the repro to understand what is the root cause of this synchronous rendering. |
|
Hi @tamuratak thank you for the PR. The issue you linked filed by my colleague and the performance profiles seems to suggest the slow performance is due to a recalculate styles + relayout calls triggered by the I am not sure we are forcing a synchronous rendering on the editor. |
Optimize rendering performance by scheduling DOM updates at the next animation frame in NativeEditContext and TextAreaEditContext. Related to #263525 and #246523.
This is one of several PRs aimed at improving smooth scrolling in the chat view, even when it contains many code blocks.
NativeEditContext._updateSelectionAndControlBoundsAfterRenderandTextAreaEditContext._renderare one of the causes of reflow during chat view scrolling as mentioned in #263525. In this PR, reflow is avoided by deferring the actual method call to the next animation frame. There have been many complaints about scrolling in the chat view, so I think optimizations like this are well justified.When this PR not merged:
When this PR not merged (
editor.editContext: false):When all PRs merged:
