revamp resize logic in demo

[jerch]

If the browser has a zoomlevel (prolly for any pixelDeviceRatio != 1) the element resizing in client.ts does not yield the same values as FitAddon.fit leading to additional resize adjustments done by the fit addon (see https://github.com/xtermjs/xterm.js/issues/4112#issuecomment-1245231518). This prolly also happens in the opposite direction for shrinking and a zoomlevel <100% (not tested though).

We might want to fix that, so ppl dont c&p faulty code resulting in nonsense resize events with poor performance in the end.

(@Tyriar - you might want to test if something similar happens in vscode, if the pixelDeviceRatio is not perfectly 1).

[Tyriar]

These inconsistencies are mainly a result of https://github.com/xtermjs/xterm.js/issues/702. I don't think it happens in VS Code, but it also reaches into private API to handle resizing similar to the fit addon.

[jerch]

So should we fix that in client.ts as well? I dont see an urgent need (know how to work around), just wonder if it makes embedders life harder, if they just c&p stuff from client.ts.

[Tyriar]

Yep we should fix, resize as a whole is a bit of a mess due to no dimensions being exposed though. VS Code has its own inconsistent size calculation and I suspect other embedders do something similar when fit doesn't meet their needs: https://github.com/microsoft/vscode/blob/9b80ed652434a6e82b3ac28c1a9a01132c8faea3/src/vs/workbench/contrib/terminal/browser/terminalInstance.ts#L591-L653

[jerch]

So to summarize - lets revamp resize logic in client.ts, to it is in line with fit addon.