Page MenuHome

BLF: Refactor of blf_font_boundbox_ex
Needs ReviewPublic

Authored by Harley Acheson (harley) on Aug 20 2022, 3:29 AM.

Details

Summary

Refactor of blf_font_boundbox_ex to make simpler and easier to
follow.


I find this function confusing with unnecessary calculations and redundant variables. This is refactored based on the following:

There are extra variables defined in the middle of the loop (gbox_xmin, gbox_xmax, gbox_ymin, gbox_ymax) that just get assigned to and then they are copied back elsewhere. They can be easily removed to simplify the code.

The left edge of the bounding box is always zero. It starts as zero (assignment to pen_x) and can never change. The only theoretical changes are if any advance were negative, but they are always positive for horizontal layouts. Kerning can be negative but is always zero for the first character of a string. Glyph left bearings can be negative but those are not used here. Its always just zero and that makes sense in that when you output a string at a particular location it will never start to the left of that. So no reason to track this.

The right edge of the bounding box we are creating is always the same as pen_x.

With above in mind half of the function goes away. It is more obvious that we are just creating a single rect that encloses the extents of the glyphs. Confirmed by tested this and current code in serial and asserting on any difference.

Removes 58 lines of code.

Diff Detail

Repository
rB Blender

Event Timeline

Harley Acheson (harley) requested review of this revision.Aug 20 2022, 3:29 AM
Harley Acheson (harley) created this revision.
Harley Acheson (harley) edited the summary of this revision. (Show Details)

Include some cleanup of blf_font_width_and_height, blf_font_width, blf_font_height

No longer using the unneeded GlyphBLF->box_* values.
Also changed a bit to align with comments by Campbell in D15765: BLF: Refactor of blf_font_boundbox_foreach_glyph

Harley Acheson (harley) edited the summary of this revision. (Show Details)Sep 20 2022, 7:37 PM

While this change seems like it may be OK, it changes some assumptions about bounding boxes - moving away from the bounding box requested by freetype to use the pixel dimensions of the bitmap.

This seems more like changing 1 method to another then a fix - while unlikely it's not impossible that filtering pixels for e.g. causes the bitmap to extend beyond the rounded pixel-bounds of the font, if we ever want to use BLF for VFont (to implement shaped text for e.g.) we might not have a bitmap representation of the glyph (although using BLF for vfont would be a much bigger change).

The refactoring in the patch seems OK, but I don't see much/any advantage in changing the way bounds are calculated - especially since it's not solving a problem anyone has reported.