-
Notifications
You must be signed in to change notification settings - Fork 632
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
Text blurry with femtovg renderer #5177
Comments
Thanks for the bug report. |
Great summary and analysis - makes a lot of sense to me. We can fix that in FemtoVG. I wonder though if it should be unconditionally nearest neighbour or if linear filtering may be desirable in some scenarios (say when blitting with a transformation). But perhaps for now flipping the default is the choice that makes the default much better and can be adjusted later if needed. |
I can confirm that your proposed fix works. This indeed also fixes #4868 |
As outlined in slint-ui/slint#5177 , we should default to nearest neighbour for the glyph atlas.
Thanks again @CryZe ❤️ |
I just tried slint for the first time. In general I judge the usability of a GUI framework based on how well it handles text, and while I noticed a few problems, it seems like font fallback and some IME support is there, which surprised me positively. Nevertheless one of the most common issues with text is unclear rendering. Turns out that it's particularly bad here in slint with the default femtovg renderer.
I however already figured out the problem. It turns out that the text is not aligned to the pixel grid. So when femtovg blits the glyphs from its glyph atlas, it uses a bilinear filter. So if the text is off by half a pixel you essentially get two source pixel averaged together per target pixel, meaning you effectively reduce the resolution of the text by half.
The left is the default text rendering with femtovg and the right is me having patched femtovg to use nearest neighbor for their glyph atlas (you can do so via the
ImageFlags
here).Now I don't know if that's the actual solution, but it at least worked around the problem for the most part. There's still some rare edge case where the two triangles making up each glyph end up blitting the texture off by 1 pixel respectively.
The text was updated successfully, but these errors were encountered: