Blurry rendering of alternate rows of text with non-integer font height #6800

New issue

Closed

opened 2023-09-08 20:57:09 +00:00 by azonenberg · 3 comments

azonenberg commented

2023-09-08 20:57:09 +00:00

(Migrated from github.com)

I'm using imgui 1.89.8 with Vulkan backend on Linux and a custom font (DejaVu Sans 12/14px and DejaVuSans Mono 12px are all affected so far, have not tried others yet).

Any time I display a single line of text, no matter how many widgets I stack in a window, everything looks fine.

But if I have a single multi-line text block the second, fourth, and successive even-numbered lines of text will appear blurry. I think this is the result of line height being a fraction of a pixel, so successive lines are displaced by about half a pixel relative to the first line and the texture doesn't map 1:1 to screen pixels.

According to the "fonts" tab of the demo window, the fonts are all fractional pixels in height despite me having asked for integer pixel size (12.46px for 12px, 14.38px for 14px).

Is there some setting I can poke to fix this? Is this a problem with how TTF fonts are loaded into the font atlas?

I'm using imgui 1.89.8 with Vulkan backend on Linux and a custom font (DejaVu Sans 12/14px and DejaVuSans Mono 12px are all affected so far, have not tried others yet). Any time I display a single line of text, no matter how many widgets I stack in a window, everything looks fine. But if I have a single multi-line text block the second, fourth, and successive even-numbered lines of text will appear blurry. I think this is the result of line height being a fraction of a pixel, so successive lines are displaced by about half a pixel relative to the first line and the texture doesn't map 1:1 to screen pixels. According to the "fonts" tab of the demo window, the fonts are all fractional pixels in height despite me having asked for integer pixel size (12.46px for 12px, 14.38px for 14px). Is there some setting I can poke to fix this? Is this a problem with how TTF fonts are loaded into the font atlas? ![text-bug1](https://github.com/ocornut/imgui/assets/998036/32d2a090-a1d9-46bb-9146-d91347974787)

azonenberg commented

2023-09-08 21:13:08 +00:00

(Migrated from github.com)

So I guess this is just a problem in general with fonts that have a height that isn't an integer number of pixels? I expected the text to simply antialias a bit further off the edge of the pixel but it seems somewhere either the font atlas or the rendered polygons are an integer number of pixels while the other is not, so the resulting resampling blurs everything vertically.

Update: I was calling atlas->AddFontFromFileTTF with the target pixel size multiplied by the content scale, and no rounding. Rounding this to the nearest pixel removed the alternating line blur, and I got a further quality improvement by setting config.PixelSnapH. So I guess this is just a problem in general with fonts that have a height that isn't an integer number of pixels? I expected the text to simply antialias a bit further off the edge of the pixel but it seems somewhere either the font atlas or the rendered polygons are an integer number of pixels while the other is not, so the resulting resampling blurs everything vertically.

ocornut commented

2023-09-09 14:08:09 +00:00

(Migrated from github.com)

So I guess this is just a problem in general with fonts that have a height that isn't an integer number of pixels?

Yes we don't technically support that properly yet unfortunately, and it has been causing lots of subtle issues. you'll need to round your numbers at loading times.

I haven't tested but I suspect if you use OversampleV = 2 it might improve the look, but expect other subtle bugs.

I've been hesitant to perform the rounding at load times for some reasons but I think I will backtrack on that and round the numbers at load time until we can improve the logic.

> So I guess this is just a problem in general with fonts that have a height that isn't an integer number of pixels? Yes we don't technically support that properly yet unfortunately, and it has been causing lots of subtle issues. you'll need to round your numbers at loading times. I haven't tested but I suspect if you use OversampleV = 2 it might improve the look, but expect other subtle bugs. I've been hesitant to perform the rounding at load times for some reasons but I think I will backtrack on that and round the numbers at load time until we can improve the logic.

ocornut commented

2023-09-11 08:05:55 +00:00

(Migrated from github.com)

I added enforcing of font size rounding in bd63a9f

Note that using io.FontGlobalScale or SetWindowFontScale(), with are legacy-ish/partially supported features but sitll somehow convenient in some situation, can still lead to unrounded sizes and same issues.

I added enforcing of font size rounding in bd63a9f Note that using io.FontGlobalScale or SetWindowFontScale(), with are legacy-ish/partially supported features but sitll somehow convenient in some situation, can still lead to unrounded sizes and same issues.