How about running resize in both terminal and conhost?

[mcpiroman]

I commented about this on #1465, but this may deserve an issue (for PR, to have separate discussion).

My best bet to fix or at least simplify this [#1465] is to not emit new resized buffer from conhost, but instead run the resize on terminall's buffer too. This way both buffers should be the same and additionally terminal will have access to context of the resize, which would e.g. enable us to track selection transform (#1368), and maybe to fix the bugs above too.

It should be at least as (in)efficient as it is now (especially over network), because despite doubled work, conhost wouldn't need to transfer the buffer back to terminal, which seems comparatively costly.

It could eventually be futher optimizied so thet when user drags window the resize runs only on terminal's buffer and is reported to conhost only when the user releases LMB (but this would reqiure to freeze sth like the conhost does when scrolling?).

And since you want to support existing 3-party terminals - they handle resize themselfs. So while the present solution should work, it will be unusual to them and may cause some troubles such as we have now (even if we resolve them on terminal side).

And finally, in passthrough mode terminal would have to resize the buffer itself.

How are you about that?

[zadjii-msft]

I typed up a response to this question in the original thread, as I think it had some bigger context that was relevant there. I'm closing this one to merge back in with the parent.