After CTRL+Scroll to zoom in and out a ton, the text gets garbled

[zadjii-msft]

From MSFT:21430356

After CTRL+Scroll to zoom in and out a ton, the text gets garbled

I scrolled with CTRL+Scroll to make it really small and really big and went back and forth. Then, I can scroll up and get garbled text that only extends a few characters but are truncated rather than wrapping.

[dash-mode]

Has anyone been working on this?
When I begin a new tab and then I change the size of the text using ctrl+scroll, I see some garbage text when I scroll up.

[zadjii-msft]

Nope, feel free to take a stab at it if you'd like. My guess is that we're not "reflowing" text that's outside of the viewport when we resize the buffer, we're merely truncating it to the new size of the buffer. There's almost certainly code in conhost's SCREEN_INFORMATION class that could help with this, though it'd have to be ported down a layer, to the TextBuffer class.

[dash-mode]

Alright, thanks for the suggestion. I will take a look at it.

[dash-mode]

window::verticalScroll is called in this function ^

Here is the definition of window::verticalScroll.

I think this is where the issue might be. But I am a little stuck here. Can someone help me out here?

[Shorotshishir]

This is the max I could get to zoom and render. I have a 1080p display this is too much!

[DHowett-MSFT]

I’m sorry, are you complaining that you made your font too big and now your font is too big?

[Shorotshishir]

@DHowett I am not complaining about my font being too big :D but saying it is not stopping! I do believe it should have a max limit, where scrolling won't have any effect. I could see the cursor growing and growing.

[zadjii-msft]

@dash-mode The function you're actually looking for is SCREEN_INFORMATION::ResizeWithReflow in screeninfo.cpp

[WSLUser]

I do believe it should have a max limit, where scrolling won't have any effect. I could see the cursor growing and growing.

I agree though probably not for exactly the same reason. I could see a potential crash occurring either with the tab, the Terminal, or potentially Windows itself (though I find that highly unlikely) or a crash in the GPU that causes a reset. It raises an availability concern and potentially other security concerns. Setting a max limit would be best but I think if it can fit on the screen, it should be permitted. I would execute some query logic based on device type to determine the visual range available for the screen.

[KoalaBear84]

Luckily I have found an issue representing my problems and then seeing it is already known for a half year. Aww.

Anyway, here is a visual I created to demonstrate. It is good to have anyway.

[zadjii-msft]

Wait a hot second, this is actually the same bug as /dup #1465 and more broadly, #4200

[ghost]

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!