Page MenuHome

UI: Use Float for Font Size Points
Changes PlannedPublic

Authored by Harley Acheson (harley) on Sep 19 2020, 7:07 PM.

Details

Reviewers
None
Group Reviewers
User Interface
Summary

This patch allows the use of floats when specifying text sizes.

Why?

This might seem like a solution in search of a problem if you only consider running Blender in English using the supplied font.

But best to first consider that "Resolution Scale" basically changes the size of the grids that UI elements are laid out into. So doubling the scale will give us larger icons and larger boxes that contain text. But how big the text is inside those boxes, relatively, is set in Themes / Text Style.

The most important reason to change things in Themes / Text Style is to accommodate a change in font that has different metrics. If you were to change the Blender font to one that has wider characters you might want to decrease the point values. Similarly if you use a font that has tall and thin glyphs (like with many Arabic fonts), then you'd want to increase the point sizes there.

And having greater granularity can come in handy. For example if you were to swap out the supplied font for one from Google's "Noto" family you will see that all the text looks slightly smaller, just because of the difference in how the characters are designed. So you'd want to increase the text size a bit. But changes of a full point size are too much.

Note that although FreeType supports sizes and positioning with fractional values with a resolution of 1/64 of a point, it does round the requested fractional font size so that the resulting EM square has whole pixel values. So the effective resolution is less than 1/64 of a point. But this patch does generally effect a visual change of an average word with changes of 0.1 of a point, even at 1.0 interface scale.

Note that this should not require any versioning code as Blender converts ints/floats when needed during file load.

Diff Detail

Repository
rB Blender

Event Timeline

Harley Acheson (harley) requested review of this revision.Sep 19 2020, 7:07 PM
Harley Acheson (harley) created this revision.

A concern with this change is we may end up allocating many more font glyphs, as two nearly identical font sizes will be considered different.

We've had reports before that the GPU runs out of memory from zooming nodes for example, this is something we worked around, however the issue of over-allocating slightly different sizes remains, and this change could make things worse.

Can you double check that with some typical-usage this isn't causing more glyphs to be allocated?

To avoid problems here, we could even keep blf_font_size taking an int, adding blf_font_size_fl for callers which intend to use floating point values. This way BLF_size(.., a / b); wont unintentionally request an entirely new font in memory because of minor floating point differences.

Note that freetype casts the float to and int (FT_F26Dot6). Suggest to re-use fonts that have the same ft_size to avoid over-allocating glyphs that end up having the same size in freetype.


Regarding this functionality in general, unless this has visible benefits with a default configuration, I'd rather not apply this or put it on hold, as these kinds of changes can introduce problems that need investigation, for only minor benefits.

Harley Acheson (harley) planned changes to this revision.Sep 20 2020, 6:03 PM

@Campbell Barton (campbellbarton) - I'd rather not apply this or put it on hold...

On hold for sure. I mostly just need this for myself internally while I experiment with other font-based dumbassery. We very likely don't need this in Blender, but not sure yet.

We've had reports before that the GPU runs out of memory from zooming nodes for example....

We really should looking into culling old glyph caches. We never really need more than about a dozen live ones at a time, but you can probably get hundreds while zooming the interface scale or zooming nodes.

Note that freetype casts the float to and int (FT_F26Dot6). Suggest to re-use fonts that have the same ft_size to avoid over-allocating glyphs that end up having the same size in freetype.

Good point. FreeType does a rounding from requested value to keep integer em widths. So probably possible to fix that perfectly by keying the cache on a resulting font metric rather than the requested size. Worth checking into.