black lines in background when using midnight commander or neovim #5070

@j4james commented on GitHub (Nov 19, 2019):

I suspect this is a duplicate of #455.

@j4james commented on GitHub (Nov 19, 2019): I suspect this is a duplicate of #455.

claunia commented

@egmontkob commented on GitHub (Nov 19, 2019):

I don't think it's a duplicate. Although that bug also has two screenshots equivalent to the one here, one of them also showing mc in particular, that bug talks about the line drawing characters (i.e. the foreground) not touching each other.

This bug is here talks about the background color (blue) not filling the entire cell, leaving a gap.

In this screenshot over here, the period (from the top of a black line to the top of the next black line) is 57 pixels. Also if you magnify and look closely at some repeated piece of text (e.g. all those "4096"s), you'll see that antialiasing goes differently in every second row. In the upper row of each blackline-separated area, horizontal lines (e.g. the ones of digits 2, 4, the serif of 1, i, r etc.) are 2 pixels tall and super crispy. In every lower row these are uglier 1 pixel half-blue-half-white antialiased + 1 pixel white + 1 pixel half-blue-half-white antialiased.

So a row's height is 28.5 pixels, each text row is presumably 28.5 pixels below the previous one, and here and there (e.g. when rendering the background) rounding to integers kicks in.

Totally sounds like a HiDPI related story.

@egmontkob commented on GitHub (Nov 19, 2019): I don't think it's a duplicate. Although that bug also has two screenshots equivalent to the one here, one of them also showing `mc` in particular, that bug talks about the line drawing characters (i.e. the foreground) not touching each other. This bug is here talks about the background color (blue) not filling the entire cell, leaving a gap. In this screenshot over here, the period (from the top of a black line to the top of the next black line) is 57 pixels. Also if you magnify and look closely at some repeated piece of text (e.g. all those "4096"s), you'll see that antialiasing goes differently in every second row. In the upper row of each blackline-separated area, horizontal lines (e.g. the ones of digits `2`, `4`, the serif of `1`, `i`, `r` etc.) are 2 pixels tall and super crispy. In every lower row these are uglier 1 pixel half-blue-half-white antialiased + 1 pixel white + 1 pixel half-blue-half-white antialiased. So a row's height is 28.5 pixels, each text row is presumably 28.5 pixels below the previous one, and here and there (e.g. when rendering the background) rounding to integers kicks in. Totally sounds like a HiDPI related story.

claunia commented

@egmontkob commented on GitHub (Nov 19, 2019):

... although the screenshot of the entire desktop is 1920x1080, which is not HiDPI, unless the screenshot taking software downscaled it in which case who knows what other nasty things it did :) @ducaale What's your monitor's resolution?

A few other things to note:

Those black lines aren't really black, just something darker than desired. It depends based on the neighboring two background colors. It's different between cyan and blue (under "Command Options Right"), between blue and cyan (under "Name Size Modify time") [yup the order of colors also seems to matter], cyan and white (under "Left File Command") etc.

There are some such vertical lines, too, namely either before or after(*) the vertical line drawing chars. (*)Presumably according to the parity, I haven't verified.

@egmontkob commented on GitHub (Nov 19, 2019): ... although the screenshot of the entire desktop is 1920x1080, which is not HiDPI, unless the screenshot taking software downscaled it in which case who knows what other nasty things it did :) @ducaale What's your monitor's resolution? A few other things to note: Those black lines aren't really black, just something darker than desired. It depends based on the neighboring two background colors. It's different between cyan and blue (under "Command Options Right"), between blue and cyan (under "Name Size Modify time") [yup the order of colors also seems to matter], cyan and white (under "Left File Command") etc. There are _some_ such vertical lines, too, namely either before or after(\*) the vertical line drawing chars. (\*)Presumably according to the parity, I haven't verified.

claunia commented

@j4james commented on GitHub (Nov 19, 2019):

You can see the same sort of DPI scaling issues in #2496, #2779, and #2790, all of which were marked as duplicates of #455. I think the title of #455 is a bit misleading, and isn't necessarily a good indication of the underlying cause of the problem.

@j4james commented on GitHub (Nov 19, 2019): You can see the same sort of DPI scaling issues in #2496, #2779, and #2790, all of which were marked as duplicates of #455. I think the title of #455 is a bit misleading, and isn't necessarily a good indication of the underlying cause of the problem.

claunia commented

2026-01-31 00:04:23 +00:00

@ducaale commented on GitHub (Nov 19, 2019):

@egmontkob Yes the resolution is 1920x1080 with 150% scaling.

@ducaale commented on GitHub (Nov 19, 2019): @egmontkob Yes the resolution is 1920x1080 with 150% scaling.

claunia commented

@egmontkob commented on GitHub (Nov 19, 2019):

You can see the same sort of DPI scaling issues in #2496, #2779, and #2790

Indeed those three bugs are the same as this one.

I think the title of #455 is a bit misleading

Or rather let's say: #455 is two technically different issues squeezed into one.

with 150% scaling

How does 150% scaling result in every second row being different? I have no idea :D

@egmontkob commented on GitHub (Nov 19, 2019): > You can see the same sort of DPI scaling issues in #2496, #2779, and #2790 Indeed those three bugs are the same as this one. > I think the title of #455 is a bit misleading Or rather let's say: #455 is two technically different issues squeezed into one. > with 150% scaling How does 150% scaling result in every second row being different? I have no idea :D

claunia commented

2026-01-31 00:04:23 +00:00

@DHowett-MSFT commented on GitHub (Nov 21, 2019):

I'm guessing that this is one of those classic D2D 0.5-pixel offset issues 😁

@DHowett-MSFT commented on GitHub (Nov 21, 2019): I'm guessing that this is one of those classic D2D 0.5-pixel offset issues :grin:

claunia commented

2026-01-31 00:04:23 +00:00

@ihor-sviziev commented on GitHub (Nov 27, 2019):

I have the same issue, workaround - press "ctrl -" one time (decrease font size), and this issue is getting fixed.

Also font size by default looks too big, for instance on Ubuntu it's usually smaller.

@ihor-sviziev commented on GitHub (Nov 27, 2019): I have the same issue, workaround - press "ctrl -" one time (decrease font size), and this issue is getting fixed. Also font size by default looks too big, for instance on Ubuntu it's usually smaller.

claunia commented

@phelps-matthew commented on GitHub (Dec 29, 2019):

Same issue. Adjusting font size does not fix, whether in json profile or ctrl +/-

@phelps-matthew commented on GitHub (Dec 29, 2019): Same issue. Adjusting font size does not fix, whether in json profile or ```ctrl +/-```

claunia commented

@ducaale commented on GitHub (Dec 30, 2019):

@phelps-matthew have you tried fontSize of 10 or 14?

@ducaale commented on GitHub (Dec 30, 2019): @phelps-matthew have you tried fontSize of 10 or 14?

claunia commented

@phelps-matthew commented on GitHub (Dec 31, 2019):

@ducaale Yes I've tried a large range of sizes. There is one particular font and size combination (Delugia Nerd Font at size 10) that did not result in lines, but this would seem to be a special case.

The other fonts I desire still result in horizontal lines even at 10 pt.

@phelps-matthew commented on GitHub (Dec 31, 2019): @ducaale Yes I've tried a large range of sizes. There is one particular font and size combination (Delugia Nerd Font at size 10) that did not result in lines, but this would seem to be a special case. The other fonts I desire still result in horizontal lines even at 10 pt.

claunia commented

@george-tsiros commented on GitHub (Jan 15, 2020):

please, someone tell me i'm not weird for thinking this shouldn't be happening. We've been rendering text for more than three decades now. Certainly it's expected that we've figured it out by now? Please

@george-tsiros commented on GitHub (Jan 15, 2020): please, someone tell me i'm not weird for thinking this shouldn't be happening. We've been rendering text for more than three decades now. Certainly it's expected that we've figured it out by now? Please

claunia commented

@michalwidera commented on GitHub (Jan 29, 2020):

I have the same issue, workaround - press "ctrl -" one time (decrease font size), and this issue is getting fixed.

Also font size by default looks too big, for instance on Ubuntu it's usually smaller.

This workaround does not help.

@michalwidera commented on GitHub (Jan 29, 2020): > I have the same issue, workaround - press "ctrl -" one time (decrease font size), and this issue is getting fixed. > > Also font size by default looks too big, for instance on Ubuntu it's usually smaller. This workaround does not help.

claunia commented

@PhilDim1 commented on GitHub (Feb 15, 2020):

Same exact issue here. Changing fonts and font size does nothing. What DOES fix this (for me) is to ensure your 'Scale and Layout' setting under Settings/Display is at 100%. Not really a solution, but perhaps someone brighter than I can fix this. This is pretty much the one issue keeping me from leaving mintty/wsltty and solely using WT.

@PhilDim1 commented on GitHub (Feb 15, 2020): Same exact issue here. Changing fonts and font size does nothing. What DOES fix this (for me) is to ensure your 'Scale and Layout' setting under Settings/Display is at 100%. Not really a solution, but perhaps someone brighter than I can fix this. This is pretty much the one issue keeping me from leaving mintty/wsltty and solely using WT. ![image](https://user-images.githubusercontent.com/40040659/74592263-8080f580-4fed-11ea-9250-71d651f3c618.png)

claunia commented

@ghost commented on GitHub (Apr 22, 2020):

:tada:This issue was addressed in #5149, which has now been successfully released as Windows Terminal Preview v0.11.1121.0.🎉

Handy links:

@ghost commented on GitHub (Apr 22, 2020): :tada:This issue was addressed in #5149, which has now been successfully released as `Windows Terminal Preview v0.11.1121.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v0.11.1121.0) * [Store Download](https://www.microsoft.com/store/apps/9n0dx20hk701?cid=storebadge&ocid=badge)

claunia commented