Open bpasero opened 1 year ago
Maybe we can do a bit of debouncing or scheduling on the next animation frame?
The debouncing will help in the sense of running this less often but we could also attempt to buy more into the measure/modify pattern so that forced layouts happen less likely (see https://web.dev/avoid-large-complex-layouts-and-layout-thrashing/#avoid-forced-synchronous-layouts)
Follow up from https://github.com/microsoft/vscode/issues/165441
When profiling window resize on Windows, this method appears as somewhat slow:
This is not entirely surprising, given it checks on
container.offsetWidth
.Maybe we can do a bit of debouncing or scheduling on the next animation frame? Editor tabs have a similar problem where we need the container width, but we do debouncing there:
https://github.com/microsoft/vscode/blob/7b70ddcd7647b531970ecc32b14bda66c90be6c9/src/vs/workbench/browser/parts/editor/tabsTitleControl.ts#L1471
Profile:
CPU-20221223T064049.zip
//cc @jrieken