Rendering problem, blurry text #5759
Comments
ghost
added
Needs-Triage
|
@fahadabdulaziz Is this the legacy console or the new Windows Terminal? (If you're just running "Command Prompt" or Are you using anything like remote desktop? This looks like it's mpeg compression or something gone wrong, but it's hard to be sure. |
zadjii-msft
added
the
Needs-Author-Feedback
|
@zadjii-msft I'm using Windows Terminal Version 0.11.1251.0 I tried disabling ClearType but nothing happened. Ass you can see in this attachment all lines are blurry and if I scroll up or down the lines re-render ok. the last line is rendered normally.
|
ghost
added
Needs-Attention
|
I have the same. It started since the last update (version 0.11.1251.0). When I first return to the window or tab, everything is clear, but then everything, except from the current command line, becomes rapidly more and more blurry until it gets so blurry as in the screenshots. That happens in seconds. Every result is blurry and it happens to every profile, PowerShell, Command Prompt, WSL, everywhere, no matter what antialiasing method I use, greyscale or cleartype.
|
|
I’m hoping to find a common thread between the two of you. What hardware-display, GPU, etc.-are you using? What font are you using? What size? Are you using display scaling? What factor? |
|
Are you enabled "Conservative Morphological Anti-Aliasing" in Intel's graphics driver? |
Intel Core i5-4460 It happens both on default font (Cascadia Mono 12pt) and Consolas 10pt.
I can find no such setting in my driver. And I am using hardware acceleration on Firefox with no problems. |
|
Processor: Intel(R) Core(TM) i7-4790T CPU @ 2.70GHz BTW I have the same problem with Edge and had it Azure Data Studio, with Azure DS I solve it by adding --disable-gpu. |
I have the same problem on the new Edge too, since the beginning. |
DHowett-MSFT
added
Area-Rendering
|
Thoughts; @miniksa suggested that we might need to offer a feature to disable hw acceleration like Chrome/Edge do. If there's no way for us to get the Intel driver to back off, we need a software solution. |
I also have the terrible idea of detecting this one bad Intel chipset and turning off diff rendering for it... |
DHowett-MSFT
removed
the
Needs-Triage
|
Somebody reported that for nVidia cards, they could get this fixed by turning off "Image Sharpening". |
|
BTW I have two card on my machine nVidia & Intel. |
|
I have the same issue, either looking at the integrated (laptop) or external screen. The thing is that it worked fine before the current version of Windows Terminal (0.11.1251.0). I also noticed that the tab of Terminal are somehow 'blinking', not sure if these are linked. |
|
I have the same issue with an nvidia card. I searched for image sharpening in my 3d settings, but it is not there. Also, when I plug my laptop into an external display, everything looks great. This issue only comes up when using the laptop's display. |
## Summary of the Pull Request Adds user settings to adjust rendering behavior to mitigate blurry text on some devices. ## References - #778 introduced this, almost certainly. ## PR Checklist * [x] Closes #5759, mostly * [x] I work here. * [ ] We need community verification that this will help. * [x] Updated schema and schema doc. * [x] Am core contributor. Discussed in Monday sync meeting and w/ @DHowett-MSFT. ## 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. 1. `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. 2. `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 - [x] Flipped them on and verified with the debugger that they are being applied to the rendering pipeline - [ ] Gave a private copy to community members in #5759 and had them try whether one, the other, or both resolved their issue.
ghost
added
the
Resolution-Fix-Committed
## Summary of the Pull Request Adds user settings to adjust rendering behavior to mitigate blurry text on some devices. ## References - #778 introduced this, almost certainly. ## PR Checklist * [x] Closes #5759, mostly * [x] I work here. * [ ] We need community verification that this will help. * [x] Updated schema and schema doc. * [x] Am core contributor. Discussed in Monday sync meeting and w/ @DHowett-MSFT. ## 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. 1. `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. 2. `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 - [x] Flipped them on and verified with the debugger that they are being applied to the rendering pipeline - [ ] Gave a private copy to community members in #5759 and had them try whether one, the other, or both resolved their issue. (cherry picked from commit d01317c)
|
If one of you would be willing to test the rendering options introduced in #5853, would you please reach out via e-mail? My address is in my profile. |
|
@bazilious reached out and is testing. Thanks! @fahadabdulaziz just to be 100% sure, can you copy the version number from our About dialog? I managed to reproduce this as well. Here's, roughly, what I did. This requires running Terminal unpackaged!
|
Both
|
|
That's really helpful. Thank you! |
|
@DHowett-MSFT Thank you for your help, I use WT version 0.11.1251.0 The problem is fixed for, after altering the card options it needs for restart, or disable and re-enable the intel card from device manager. Looks like I don't need to wear glasses anymore 😁 |
|
🎉This issue was addressed in #5853, which has now been successfully released as Handy links: |
|
Same here, Venue 11 Pro, Intel HD 4200 i5-4300Y, two screens, both 1080p, the internal one is an HiDPI display (125% scaling), the external one is not HiDPI (100% scaling). The problem only affects the external monitor. If I move the Terminal window to the HiDPI monitor it renders just fine. That's exactly the same issue affecting Chromium/Edge/Electron-based garbage. I can't live with GPU acceleration disabled as my ULP i5-Y cpu is too short in TDP to handle cpu-based rendering. I will try to disable differential rendering only to see if it helps. |
|
Test results. I would really consider to ship with forceFullRepaint enabled until you get a better idea of what is causing this issue. Better to ship a sub-optimal rendered which can be faster enabling that experimental partial redraw feature than shipping something which simply doesn't work for an unspecified class of users. |
|
I mean we know exactly what's causing this, and that it's out of our control:
There's not much we can do ourselves about a 5 years old drivers bug, except provide an escape hatch for users affected by it to work around it. Differential drawing gets us such a dramatic performance increase that we're not about to revert that for the majority of our userbase without evidence that this "melting text" bug affects the majority of users. |
|
Sure, but how you would explain my main screen not being affected by this? Are you 100% sure it does not relate to HiDPI, external HDMI or something else? Are you 100% sure it does only affect 5-years old hardware? If the answer is yes, then I perfectly agree on your point. |
## Summary of the Pull Request Adds user settings to adjust rendering behavior to mitigate blurry text on some devices. ## References - microsoft#778 introduced this, almost certainly. ## PR Checklist * [x] Closes microsoft#5759, mostly * [x] I work here. * [ ] We need community verification that this will help. * [x] Updated schema and schema doc. * [x] Am core contributor. Discussed in Monday sync meeting and w/ @DHowett-MSFT. ## 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. 1. `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. 2. `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 microsoft#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 - [x] Flipped them on and verified with the debugger that they are being applied to the rendering pipeline - [ ] Gave a private copy to community members in microsoft#5759 and had them try whether one, the other, or both resolved their issue.
|
Hi guys, I am too suffering from smudge fonts and I tend to believe LuKePicci is right. On any of the external monitors, which are not HiDPI the fonts look smudge. On the laptop monitor the fonts looks crystal sharp. Hardware: I tried everything on this thread including the below but non fixed the issue.
I also wanted to try to disable scaling on high DPI on the app settings, but couldn't find how to do it for an app from the store. If you know how can this be done, I would gladly test and report the results. https://www.thewindowsclub.com/fonts-appear-blurred-windows-8/ Please advise. Thanks for the help :-)
|
|
For reference I found out there is a relation between the blurry problem and AnyDesk app after using it for a remote session, a similar problem happens with Visual Studio, the solution I found is killing DWM.exe process (which is a windows process responsible managing app windows). |
|
Guys, is there any official way to stop smoothing fonts on this app? I believe this is the issue. Thanks! |
|
@mic345 there was an entire discussion above the comment field on this issue that contains information on disabling font smoothing in your display adapter's configuration or in the terminal settings. It's even on our troubleshooting page. |
|
@DHowett, thanks for the quick reply!! If you mean Take care! |
|
So, it looks like your complaint is actually about subpixel rendering? Your screenshot looks pretty much like any other windows application that's primarily text has over the past 15 years. 😄 Disable that by setting |
THANK YOU!!! 🙏🙏🙏 |
|
BTW, an idea -- for people who disable the smooth edge fonts through Microsoft OS options (or in general on the OS level), maybe it makes sense to set the default antialiasingMode to aliased? In a way it's like obeying the dark mode user setting on the OS level. Anyway, it's just an idea, thanks a lot for the help! |
|
I'm actually somewhat surprised that we don't automatically follow that setting. Thanks for noticing! |
|
I know this is an old thread, but I have had the same blurry text problem since the earliest releases. However, the reply (#5759 (comment)) by reli-msft about "Conservative Morphological Anti-Aliasing" finally allowed me to fix the problem. My computer uses an Intel HD Graphics 4600 card - what may not be obvious to some is that the above-mentioned anti-aliasing option is located in the settings for 3D. In my case the option was set to "Override Application Settings". The other choices are "Enhance Application Settings" and "Turn Off", and the latter finally fixed the problem! I can now use Windows Terminal in all its glory :-) It seems strange (to me, anyway) that a 3D rendering option should affect a text terminal (especially since Windows Terminal is the only app that seems to be affected, and I've been using the same machine for coding for over 4 years), but at least it works now. For anyone else still battling with fuzzy fonts, check the 3D rendering options of your graphics cards. As counterintuitive as it seems, there's a good chance a 3D option is affecting text rendering. |
On my system, it's here:
Another setting to watch out for is this one: |
|
Hi everyone. I'm using an intel card and an Nvidia card. I disabled the CMAA feature in the 3D tab in the intel card and the font is clear now. (The CMAA can be set to disabled, override application settings, or enhance application settings.) Sorry, it looks like the language cannot be changed in the intel setting app. I've highlighted the disable option in the below screenshot. |
Environment
Microsoft Windows [Version 10.0.18363.778]
Steps to reproduce
I got this bug on last update!
Expected behavior
Text should be clear.
Actual behavior
I get blurry text then renders good then bad, weird rendering!
As you see first 5 lines are good, the rest are blurry. the good lines came after scrolling.
Mean the whole screen goes blurry then when scrolling it renders good!
I use CMD by the way I don't know about PS
The text was updated successfully, but these errors were encountered: