TLDR; Following is the continuation of #7669 moving away from imprecise (integer-based) canvas-text metrics into the relative font metrics encoded within the font itself (read by https://opentype.js.org/font-inspector.html).

Business value:

• Improved text rendering performance i.e. during resize / undo-redo etc. by completely eliminating expensive baseline calculation (no DOM-base calculation, nor relying on canvas metrics, just simple math with constants).
• Due to the above, it also improved consistency across browsers, not relying on related DOM inconsistencies and allowing server-side use cases.
• Removed "bouncing" of text during resize, due to more precise calculation based on relative font metrics.
• Maintained comparable layout shift as with DOM baseline measurements. In certain scenarios (especially when zoomed-in) it's a bit better, in some other situations its a bit worse (depending on a font & browser).

Technical details:

• Hardcoded metrics for default fonts
  • We could read the metrics for custom fonts and extend the hardcoded ones in the future
• Replaced half of the line gap in feat: text measurements based on canvas metrics #7669 with the whole line gap due to a smaller layout shift across the default fonts

Todo:

• Add changelog
• Test stability across different browsers
• Test stability across different OSs
• Double-check past shift issues in Safari
• Double-check deprecating the baseline prop
• Embed a Helvetice-like font with hardcoded metrics - right now using default MacOS Helvetica metrics, which might not work well outside MacOS
  • not needed for now, fallbacking to similar fonts when Helvetica is not present does not result in layout shifts
• Update SVG export to use alphabetic baseline & vertical offset calculated out of font metrics
  • the hardcoded vertical offset could break exports based on SVG, which do not count with the offset (i.e. PDF export)
• Remove offset introduced in feat: improve text measurements in bound containers #6187 which causes layout shifts in text containers
• Remove rounding of font sizes for Safari as it no longer does it

Related issues:

• Subpixel rendering issues across browsers when resizing small text slowly (line height is bouncing). Turning imageSmoothingEnabled on/off didn't have any effect. Noticeable mostly on lower PPI with devicePixelRatio == 1.
• Performance bottleneck remains re-generating the element shape on every single resize, which keeps the GPU busy and delays the browser's plans to re-schedule new tasks - results in a lot of dropped frames, even though there is a place for few more tasks, as visible on the screenshot below.
• Safari does not handle well scaling of textarea when zoomed in, which results in blurry text inside the wysiwyg editor.
• Safari (16 and older) - during text resize the fonts seem rounded which does not deliver the smoothest experience. Could be related to https://bugs.webkit.org/show_bug.cgi?id=46987 - the fix landed in Safari TP 174 (released july 23), fixed likely since 17.0. (october 23).
• Text in wysiwyg is often cut (both horizontally and vertically), especially in Virgil, as the glyphs often reach outside our metrics.
• Selection bounding box vs the text-area bounding box are slightly off.
• Horizontal shift in some cases, unrelated to the baseline itself feat: text measurements based on font metrics #7693 (comment).

Comparison:

• When resizing 333 text elements
• Shows ~75% task time reduction (completely removing force layout)
• Shows gaps between tasks waiting for GPU to finish (next bottleneck is rendering)