Dear emacs-devel,

Recently I've been trying to mold Corfu to render every string in every face in pixel precision but I've run into some slight performance issues when truncating strings. The motivation for this is `truncate-string-to-width` not only does not speak pixels, but also doesn't understand composed characters such as emojis. It just chops off the emoji byte sequence in the middle as described in the PR, so I had to write a custom `truncate-string-to-pixel-width` function using `string-glyph-split` and `string-pixel-width` to measure character widths, which seems... silly.

I've looked into how to get the width of a glyph from a font object by employing some dark magic of undocumented internal functions and wrongly documented functions such as `char-displayable-p`, `font-info`, `lglyth-width`, `lgstring-glyph`, `open-font` etc in combination of `composition-get-gstring`, which is correct and fast enough.... for glyph strings with no faces. Then I looked into reverse engineering the face font selection process, which quickly pushed the run time up 2 orders of magnitude due to the anonymous face + face attribute inheritance + face lists madness. Then when I realized I still didn't deal with display text properties, I threw my hands up.

It'd be really nice if we could have a really performant C function that can truncate strings correctly and preferably in pixel precision. Alternatively, a `glyph-pixel-width` that implements a fast path in C that's somewhat akin to the process I described above, but also handles display text properties correctly would be nice.

I don't really know enough about Emacs C internals WRT to font rendering to implement this so I'm just throwing this idea out there.

Does this make sense?

Jimmy Yuen Ho Wong