-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Console doesn't handle colored regions when reflowed #32
Comments
So this is basically because we don't know the difference between a space character that was purposefully emitted and just an empty cell in the buffer. When we resize, we optimize things a little bit by just filling the rest of the row with the last color we saw (as we resize). This causes the rest of the row to fill up with the colors of the last character. I can make it a bit better, but it will clear out any colored spaces at the end of the row: See how the last two spaces of the white column were reset. Might be an acceptable hit considering that resizing is already an AWFUL perf path. (opened msft:14115086 to track) |
Thanks for looking into this guys. IMO your suggestion of "I can make it a bit better, but it will clear out any colored spaces at the end of the row" looks more acceptable to me than the current behavior. Curious what others think. Windows Version: Microsoft Windows [Version 10.0.16299.15] |
FWIW, this isn't a problem that's unique to Console - Hyper also struggles to handle this scenario: |
I've also seen this issue in hyper (and VS Code terminal window), but assumed it was something common to all of them and "lower level" in Windows. |
That's correct, Hyper and others all query an underlying conhost, so if we've got it wrong then it will be wrong for everyone. |
I'm sure it's all part of the same thing - this also affects underlined text. |
…. I was worng. My theory was "fuck perf, let's do it right, and figure out perf later". It didn't work. This wraps lines super weird, probably because I'm copying the whole line to the right side of the row, which is then starting to mark it as wrapped. Also like the test doesn't even pass.
bunch of todos. It also totally takes care of #12567 as well
## THE WHITE WHALE This is a fairly naive fix for this bug. It's not terribly performant, but neither is resize in the first place. When the buffer gets resized, typically we only copy the text up to the `MeasureRight` point, the last printable char in the row. Then we'd just use the last char's attributes to fill the remainder of the row. Instead, this PR changes how reflow behaves when it gets to the end of the row. After we finish copying text, then manually walk through the attributes at the end of the row, and copy them over. This ensures that cells that just have a colored space in them get copied into the new buffer as well, and we don't just blat the last character's attributes into the rest of the row. We'll do a similar thing once we get to the last printable char in the buffer, copying the remaining attributes. This could DEFINITELY be more performant. I think this current implementation walks the attrs _on every cell_, then appends the new attrs to the new ATTR_ROW. That could be optimized by just using the actual iterator. The copy after the last printable char bit is also especially bad in this regard. That could likely be a blind copy - I just wanted to get this into the world. Finally, we now copy the final attributes to the correct buffer: the new one. We used to copy them to the _old_ buffer, which we were about to destroy. ## Validation I'll add more gifs in the morning, not enough time to finish spinning a release Terminal build with this tonight. Closes #32 🎉🎉🎉🎉🎉🎉🎉🎉🎉 Closes #12567
## THE WHITE WHALE This is a fairly naive fix for this bug. It's not terribly performant, but neither is resize in the first place. When the buffer gets resized, typically we only copy the text up to the `MeasureRight` point, the last printable char in the row. Then we'd just use the last char's attributes to fill the remainder of the row. Instead, this PR changes how reflow behaves when it gets to the end of the row. After we finish copying text, then manually walk through the attributes at the end of the row, and copy them over. This ensures that cells that just have a colored space in them get copied into the new buffer as well, and we don't just blat the last character's attributes into the rest of the row. We'll do a similar thing once we get to the last printable char in the buffer, copying the remaining attributes. This could DEFINITELY be more performant. I think this current implementation walks the attrs _on every cell_, then appends the new attrs to the new ATTR_ROW. That could be optimized by just using the actual iterator. The copy after the last printable char bit is also especially bad in this regard. That could likely be a blind copy - I just wanted to get this into the world. Finally, we now copy the final attributes to the correct buffer: the new one. We used to copy them to the _old_ buffer, which we were about to destroy. ## Validation I'll add more gifs in the morning, not enough time to finish spinning a release Terminal build with this tonight. Closes #32 🎉🎉🎉🎉🎉🎉🎉🎉🎉 Closes #12567 (cherry picked from commit 855e136)
## THE WHITE WHALE This is a fairly naive fix for this bug. It's not terribly performant, but neither is resize in the first place. When the buffer gets resized, typically we only copy the text up to the `MeasureRight` point, the last printable char in the row. Then we'd just use the last char's attributes to fill the remainder of the row. Instead, this PR changes how reflow behaves when it gets to the end of the row. After we finish copying text, then manually walk through the attributes at the end of the row, and copy them over. This ensures that cells that just have a colored space in them get copied into the new buffer as well, and we don't just blat the last character's attributes into the rest of the row. We'll do a similar thing once we get to the last printable char in the buffer, copying the remaining attributes. This could DEFINITELY be more performant. I think this current implementation walks the attrs _on every cell_, then appends the new attrs to the new ATTR_ROW. That could be optimized by just using the actual iterator. The copy after the last printable char bit is also especially bad in this regard. That could likely be a blind copy - I just wanted to get this into the world. Finally, we now copy the final attributes to the correct buffer: the new one. We used to copy them to the _old_ buffer, which we were about to destroy. ## Validation I'll add more gifs in the morning, not enough time to finish spinning a release Terminal build with this tonight. Closes #32 🎉🎉🎉🎉🎉🎉🎉🎉🎉 Closes #12567 (cherry picked from commit 855e136)
🎉This issue was addressed in #12637, which has now been successfully released as Handy links: |
🎉This issue was addressed in #12637, which has now been successfully released as Handy links: |
## THE WHITE WHALE This is a fairly naive fix for this bug. It's not terribly performant, but neither is resize in the first place. When the buffer gets resized, typically we only copy the text up to the `MeasureRight` point, the last printable char in the row. Then we'd just use the last char's attributes to fill the remainder of the row. Instead, this PR changes how reflow behaves when it gets to the end of the row. After we finish copying text, then manually walk through the attributes at the end of the row, and copy them over. This ensures that cells that just have a colored space in them get copied into the new buffer as well, and we don't just blat the last character's attributes into the rest of the row. We'll do a similar thing once we get to the last printable char in the buffer, copying the remaining attributes. This could DEFINITELY be more performant. I think this current implementation walks the attrs _on every cell_, then appends the new attrs to the new ATTR_ROW. That could be optimized by just using the actual iterator. The copy after the last printable char bit is also especially bad in this regard. That could likely be a blind copy - I just wanted to get this into the world. Finally, we now copy the final attributes to the correct buffer: the new one. We used to copy them to the _old_ buffer, which we were about to destroy. ## Validation I'll add more gifs in the morning, not enough time to finish spinning a release Terminal build with this tonight. Closes #32 🎉🎉🎉🎉🎉🎉🎉🎉🎉 Closes #12567 (cherry picked from commit 855e136)
Your Windows build number: (Type
ver
at a Windows Command Prompt)FCU
What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots)
Expected:
Folders' colored background should only extend to the end of the folder name:
Actual:
Lines with folders that are last item on line extend folder background coloring to right hand end of line:
See the following for an example of where it goes very wrong:
And it gets worse when lines wrap!
References
Thanks to @jmorrill for reporting here: https://twitter.com/jmorrill/status/915982968094580736
The text was updated successfully, but these errors were encountered: