layout trashing in WorkbenchLayout#layout

[jrieken]

• record performance and reload
• (expensive) layout trashing happens WorkbenchLayout#layout

I fiddled with this and it seems to be caused by these lines https:/Microsoft/vscode/blob/2f28e6ba8ae02a51d20e2c85fd8cd702fc8de37e/src/vs/workbench/browser/layout.ts#L547-L554

Question are

• this looks like a workaround for something. is that still needed?
• is there a better way to achieve the workaround, e.g. not having it during the main layout call?

[bpasero]

I think this code is obsolete once #50853 is tackled, which I think @sbatten and @joaomoreno are going to look into.

[jrieken]

rewriting the layout sounds like a bigger issue... isn't there a short term 'fix'? There is potential for saving lots of start-up perf time (~100ms)

[bpasero]

@jrieken its not really a rewrite, rather using what the grid widget already provides and has battle-tested in the editor area.

[joaomoreno]

Good investigation. But it would be a waste of time to go through that old code now... Let's close it since #50853 will be tackled pretty soon.

[jrieken]

I know everyone is busy with other things but upon a second look I don't this is related to layouting...

Those lines (some of them are from 2015) try to recover from some chrome behaviour we seem to have observed but not understood. It's not really part of layouting but I guess the layout-function was a convenient place for that layout-fixing-when-something-weird-happened-logic. With that in mind I think changing to a grid or whatever logic won't help.

I have removed those lines and it seems nothing has changed, I could also not reproduce #6810 without those lines. So, I call it good without those lines and I leave it up to @bpasero to double check.

[bpasero]

If this still happens, an alternative solution would be to move this code into the next animation frame and thus take it out of the critical startup path.