Hi, we’re using FSlateDrawElement::MakeText in NativePaint as an optimization to draw a large amount of damage number all at once. We were investigating the feasibility of using SDF fonts to avoid filling up the Font Atlas which was creating some bad hitches when it was flushed. Everything looks doable except for the fact that MakeText does not seem to implement some logic that’s required to draw an SDF font, it always rasterizes it. I noticed that MakeShapedText does take this into account and will draw SDF fonts as intended (but looks more complicated to set up since it requires a shaped glyph sequence). Is it by design that MakeText doesn’t do this same logic (and silently falls back to a rasterized font), or is that an oversight?
Looking through the history of the commits I wasn’t able to find any reasoning for the SDF code to only be in the shaped text function. It’s possible that implementing SDF compliant code to both methods was deemed unnecessary at the time, or that they wanted to keep MakeText simple.
SDF fonts in general shouldn’t strictly require shaped text so modifying MakeText with the changes to MakeShapedText should be possible. Although the safest path forward would be use MakeShapedText.
Interesting, that’s good to know. We’ll probably just use MakeShapedText if we go this route rather than modify the engine, but I guess you can consider this a quality of life feature request to support SDF through both code paths. Thanks.