12/29/2023 0 Comments Windows fonty blurryvarious fonts and sizes (see screenshot).I tried everything on this thread including the below but non fixed the issue. > wmic path win32_VideoController get name Model name : Intel(R) Core(TM) i7-8665U CPU 1.90GHz Gave a private copy to community members in microsoft#5759 and had them try whether one, the other, or both resolved their issue. 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. Reverting microsoft#778 completely would also resolve this, but it would give back our largest performance win in the whole Terminal project. microsoft#778 introduced this, almost certainly. I will try to disable differential rendering only to see if it helps. I can't live with GPU acceleration disabled as my ULP i5-Y cpu is too short in TDP to handle cpu-based rendering. 0, so if there was gpu acceleration in there that was worked fine. That's exactly the same issue affecting Chromium/Edge/Electron-based garbage. ( edit: additionally, if I put the Terminal window in between of the two displays such that the scaling factor of the smaller HiDPI screen is applied, the half of the window still on the bigger non-HiDPI screen is of course oversized and "out of focus" the usual way a non-HiDPI aware app, but doesn't dynamically melt on user interaction like it does when the scaling is that one of the non-HiDPI screen) If I move the Terminal window to the HiDPI monitor it renders just fine. The problem only affects the external monitor. 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). Gave a private copy to community members in #5759 and had them try whether one, the other, or both resolved their issue. Flipped them on and verified with the debugger that they are being applied to the rendering pipeline Reverting #778 completely would also resolve this, but it would give back our largest performance win in the whole Terminal project. One, the other, or both of these may be field-applied by users who are experiencing this behavior. The theory is that this will sidestep any driver bugs or hardware variations. `` - This one uses the software WARP renderer instead of using the hardware and display driver directly. On every single frame paint, we'll invalidate the entire screen and repaint it.Ģ. `` - This one restores the pre-778 behavior to the Terminal. 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.ġ. As we're really close to ship, I'm offering two options to let people in this situation escape it on their own. 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. Discussed in Monday sync meeting and w/ Detailed Description of the Pull Request / Additional comments * We need community verification that this will help. #778 introduced this, almost certainly. Adds user settings to adjust rendering behavior to mitigate blurry text on some devices.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |