Announcement

Collapse
No announcement yet.

FreeType Merges New "SDF" Renderer For High Quality Text Rendering In Games, Etc

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • arQon
    replied
    We used to use FreeType for text in games. The only real negative to it is that you can't support an infinite number of fonts / font resolutions, because each one HAS to be turned into a bitmap for the performance to not be unusably bad.

    I'm not sure how this changes that, if at all, but I don't see any sane way in which it even could. SDF may make it so that 36pt text on a 4K display looks better than with the old code, but it's still going to take FAR longer to render than an entire 3D world does, so it'll STILL have to be rendered to texmaps on a per font/resolution pair basis first.

    And yes, there are no issues with correctly rendering the anti-aliasing pixels with FreeType: but it DOES take a fair degree of care to not screw it up. However, we never even tried to use ClearType (i.e. subpixel color-based AA), because it was implicit that it would never work as well as greyscale when the background is non-uniform.

    Leave a comment:


  • faxgeraet
    replied
    Originally posted by faxgeraet View Post
    Understandable though as freetype supports stem darkening only with the cff driver and the autofitter but with the truetype driver.
    Clarification: Stem darkening is not supported with the truetype driver.

    Leave a comment:


  • faxgeraet
    replied
    Originally posted by clapbr View Post

    Text rendering is very subjective to taste and displays. QT text looks great on my 1080p 96dpi display, GTK used to be worse - now it's fine but still color fringy on dark backgrounds for me (cairo still defaults to lcdlegacy - a terrible filter), plus fonts looking too bold on light backgrounds and too thin on dark backgrounds because of bad blitting.
    It's not a subpixel layout issue, just an effect of lack of proper blending and/or gamma correction.

    Some links about the issue:


    https://bugs.chromium.org/p/chromium...tail?id=882264
    https://www.freetype.org/freetype2/d...g-general.html
    Qt supports proper gamma corrected alpha blending with otf fonts, e.g. cantarell. This is especially apparent for light text on dark background as often seen in terminals or dark themes. If you find a good otf monospace font, text in qt based terminals can look really good while avoiding this color fringing mess.

    Its a bit of an odd behaviour as this blending type is only enabled specifically for otf fonts. Understandable though as freetype supports stem darkening only with the cff driver and the autofitter but with the truetype driver.

    Leave a comment:


  • clapbr
    replied
    Originally posted by QwertyChouskie View Post

    Weird, on my low DPI screens, QT text always looks notably worse compared to GTK-rendered text (RGB anti-aliasing on both). Mainly, vertical lines that should be 1 crisp pixel wide tend to instead be blurred over 2 pixels. Now that I have a 13" laptop with a 1080p screen, it's kinda a moot point, but on my old system every time I had to use a QT app it felt very uncomfortable. To make things worse, on Ubuntu at least, GTK at least defaults to RGB subpixel anti-aliasing, while QT defaults to grayscale anti-aliasing.

    If you notice visible color fringing on text when enabling RGB smoothing, it may mean that perhaps you have a BGR, VRGB, or VBGR subpixel layout, as subpixel smoothing should never result in obvious fringing.
    Text rendering is very subjective to taste and displays. QT text looks great on my 1080p 96dpi display, GTK used to be worse - now it's fine but still color fringy on dark backgrounds for me (cairo still defaults to lcdlegacy - a terrible filter), plus fonts looking too bold on light backgrounds and too thin on dark backgrounds because of bad blitting.
    It's not a subpixel layout issue, just an effect of lack of proper blending and/or gamma correction.

    Some links about the issue:


    https://bugs.chromium.org/p/chromium...tail?id=882264

    Leave a comment:


  • QwertyChouskie
    replied
    Originally posted by clapbr View Post
    Great but no one even cares to gamma correct and alpha blend glyphs properly on Linux (except QT), I doubt big apps will actually use msdf but I'd really love to see it in a browser instead of chromium and firefox crappy rendering (grayscale AA looks like that). If you enable RGB then you have firefox and chromium.

    I don't want unequal blurry glyphs or shitty color-fringy text all over the place, FIX THIS CRAP and stop blaming freetype2 - the tools and recomendations are on docs. Implement alpha blending or blindly apply a 1.8 gamma correction or your text WILL look like shit on lo-dpi screens.
    Weird, on my low DPI screens, QT text always looks notably worse compared to GTK-rendered text (RGB anti-aliasing on both). Mainly, vertical lines that should be 1 crisp pixel wide tend to instead be blurred over 2 pixels. Now that I have a 13" laptop with a 1080p screen, it's kinda a moot point, but on my old system every time I had to use a QT app it felt very uncomfortable. To make things worse, on Ubuntu at least, GTK at least defaults to RGB subpixel anti-aliasing, while QT defaults to grayscale anti-aliasing.

    If you notice visible color fringing on text when enabling RGB smoothing, it may mean that perhaps you have a BGR, VRGB, or VBGR subpixel layout, as subpixel smoothing should never result in obvious fringing.

    Leave a comment:


  • clapbr
    replied
    Great but no one even cares to gamma correct and alpha blend glyphs properly on Linux (except QT), I doubt big apps will actually use msdf but I'd really love to see it in a browser instead of chromium and firefox crappy rendering (grayscale AA looks like that). If you enable RGB then you have firefox and chromium.

    I don't want unequal blurry glyphs or shitty color-fringy text all over the place, FIX THIS CRAP and stop blaming freetype2 - the tools and recomendations are on docs. Implement alpha blending or blindly apply a 1.8 gamma correction or your text WILL look like shit on lo-dpi screens.

    Leave a comment:


  • ddriver
    replied
    Yeah, multichannel is the way to go, but oddly it doesn't seem to be used all that much.

    Leave a comment:


  • programmerjake
    replied
    was hoping they would include a multi-channel distance field since that's the point for https://github.com/Chlumsky/msdfgen which they use as a reference.

    Leave a comment:


  • franglais125
    replied
    Originally posted by tildearrow View Post
    Is there any available comparison image?
    I was going to say this. Perfect example of "a picture is worth a thousand words".

    Leave a comment:


  • tildearrow
    replied
    Is there any available comparison image?

    Leave a comment:

Working...
X