-
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
Add renderer settings to mitigate blurry text for some graphics devices #5853
Conversation
…o permit users who are having graphical troubles with full acceleration.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aced it on the first go.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Absolutely nailed it.
Don't automerge this - the bot will delete the wonderful and carefully-crafted comment! It's my job to follow up on that, but I haven't because of v1 magic. |
🎉 Handy links: |
I'm experiencing this problem, it is mostly slight and probably at this point an older intel+nvidia laptop. I notice that in the Wsl Ubuntu areas that haven't changed (in htop for example) get blurry, it seem with the Nvidia set it is worse more quickly, and with Intel set it still happens. |
@j0nny55555 Do either of the settings added in this PR ( |
Summary of the Pull Request
Adds user settings to adjust rendering behavior to mitigate blurry text on some devices.
References
PR Checklist
Detailed Description of the Pull Request / Additional comments
When we switched from full-screen repaints to incremental rendering, it seems like we exposed a situation where some display drivers and hardware combinations do not handle scroll and/or dirty regions (from
IDXGISwapChain::Present1
) without blurring the data from the previous frame. As we're really close to ship, I'm offering two options to let people in this situation escape it on their own. We hope in the future to figure out what's actually going on here and mitigate it further in software, but until then, these escape hatches are available.experimental.rendering.forceFullRepaint
- This one restores the pre-778 behavior to the Terminal. On every single frame paint, we'll invalidate the entire screen and repaint it.experimental.rendering.software
- This one uses the software WARP renderer instead of using the hardware and display driver directly. The theory is that this will sidestep any driver bugs or hardware variations.One, the other, or both of these may be field-applied by users who are experiencing this behavior.
Reverting #778 completely would also resolve this, but it would give back our largest performance win in the whole Terminal project. We don't believe that's acceptable when seemingly a majority of the users are experiencing the performance benefit with no detriment to graphical display.
Validation Steps Performed