feature request: using preventDefault on beforeinput event for improved performance

[SimonSiefke]

When typing in VSCode, the input events get sent to a hidden textarea. Whenever the hidden textarea's value changes, recalulate style and layout work is done by the browser:

There could be an optimization by using event.preventDefault() on the textarea beforeinput event. This would prevent the default behaviour of the browser of updating the value of the textarea, reducing the recalulate style and layout work done by the browser.

The beforeinput event contains the data that would be inserted into the textarea, for example:

{
  "type": "insertText", 
  "data": "a"
}

This data can be used to trigger an _onType event to update the editor:

this._onType.fire({
  positionDelta: 0,
  replaceNextCharCnt: 0,
  replacePrevCharCnt: 0,
  text: data || ''
});

I have made a draft PR here: #189226

Performance profile with beforeinput optimization

With the beforeinput optimization enabled, there are less recalculate style layout events:

Performance Comparison

Name	Before	After
Average recalculate style	0.83325ms	0.504ms
Average layout	0.5935ms	0.284ms
Average pre-paint	0.375ms	0.406ms
Average paint	0.2475ms	0.28ms
Average per event	2.01ms	1.474ms

Detailed performance events

Before

event 1

• 0.12ms recalculate style
• 0.17ms layout
• 0.46ms recalculate style
• 0.1ms layout
• 0.34ms recalculate style
• 0.19ms layout
• 0.3ms pre-paint
• 0.17ms paint

event 2

• 0.062ms recalculate style
• 0.14ms layout
• 0.23 ms recalculate style
• 0.085ms layout
• 0.39ms recalculate style
• 0.44ms layout
• 0.34ms pre-paint
• 0.31ms paint

event 3

• 0.071ms recalculate style
• 0.23ms layout
• 0.3ms recalculate style
• 0.094ms layout
• 0.57ms recalculate style
• 0.24ms layout
• 0.49ms pre-paint
• 0.19ms paint

event 4

• 0.11ms recalculate style
• 0.14ms layout
• 0.25ms recalculate style
• 0.095ms layout
• 0.43ms recalculate style
• 0.45ms layout
• 0.37ms pre-paint
• 0.32ms paint

After

event 1

• 0.33ms recalculate style
• 0.18ms layout
• 0.36ms pre-paint
• 0.21ms paint

event 2

• 0.55ms recalculate style
• 0.48ms layout
• 0.48ms pre-paint
• 0.49ms paint

event 3

• 0.4ms recalculate style
• 0.2ms layout
• 0.35ms pre-paint
• 0.2ms paint

event 4

• 0.51ms recalculate style
• 0.22ms layout
• 0.32ms pre-paint
• 0.2ms paint

event 5

• 0.73ms recalculate style
• 0.34ms layout
• 0.52ms pre-paint
• 0.3ms paint

With an average time ~15ms per frame (including javascript) in the chrome devtools performance tab, reducing this time by ~0.5ms would be a ~3% improvement.

Contrary to the devtools performance tab, the javascript profiler tab shows much less time spent in javascript. With an average time 5ms-7ms per frame (including javascript), reducing this time by ~0.5ms would be a 8% or more improvement.

Accessibility

Since screenreader users might rely on the textarea value updating, there could be either a setting to enable/disable this optimization
or this optimization could be automatically enabled/disabled depending on whether or not a screenreader is detected.

[vscodenpa]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[vscodenpa]

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[vscodenpa]

🙁 In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[alexdima]

I hope adopting the EditContext api will improve perf in this area -- #207700