-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
revamp resize logic in demo #4113
Comments
These inconsistencies are mainly a result of #702. I don't think it happens in VS Code, but it also reaches into private API to handle resizing similar to the |
So should we fix that in |
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 |
So to summarize - lets revamp resize logic in client.ts, to it is in line with fit addon. |
A double resize could happen due to the mismatch in canvas vs device pixel widths Fixes xtermjs#4113
If the browser has a zoomlevel (prolly for any pixelDeviceRatio != 1) the element resizing in
client.ts
does not yield the same values asFitAddon.fit
leading to additional resize adjustments done by the fit addon (see #4112 (comment)). 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).
The text was updated successfully, but these errors were encountered: