[Leonard Hecker (lhecker)]

81b7e54 caused a regression in SetConsoleWindowInfo and any other
function that used the WriteToScreen helper. This is because it
assumes that it can place the viewport anywhere randomly and it was
written at a time where TriggerScroll didn't exist yet (there was
no need for that (also not today, but that's being worked on)).

Caching the viewport meant that WriteToScreen's call to
TriggerRedraw would pick up the viewport from the last rendered
frame, which would cause the intersection of both to be potentially
empty and nothing to be drawn on the screen.

This commit reverts 81b7e54 as I found that it has no or negligible
impact on performance at this point, likely due to the overall
vastly better performance of conhost nowadays.

Closes #15932

Validation Steps Performed

• Scroll the viewport by entire pages worth of content using
  SetConsoleWindowInfo - see Conhost window is not refreshed after software scroll #15932
• The screen and scrollbars update immediately ✅

[Dustin L. Howett (DHowett)]

HAH. But then, shouldn't we get rid of the entire cached viewport? We're just kicking the "torn state" can down the road...

[Leonard Hecker (lhecker)]

In the past scrolling was entirely implicit in the renderer as it computed the scroll and its invalidation just from the previous and current viewport. Nowadays we also got explicit scrolling, presumably for ConPTY edit: it was added with v2. Unfortunately (and similar to other parts here), the old code never got removed/unified and so we need to retain the behavior for both.