kbts_BreakEntireString* always runs full Unicode breaking (script, direction, word, line, grapheme), and there’s no way to disable specific break types via kbts_break_config_flags.
In a per‑frame UI text pipeline this is too slow. Blink does a lightweight run segmentation step (script + direction/orientation + emoji presentation) and then caches shaping at word/space granularity, which I'm trying to do as well. Profiling shows most time inside kbts__BreakAddCodepoint, with the line‑break state machine dominating (line‑break history switches).
Is there an intended fast path for run segmentation that I’m missing?
Maybe break‑type masks so I can disable line‑break (and optionally others) when I only need script/direction?
Activity
4
JimmyLefevre9mo agoOut of curiosity, what kind of speedup are you looking for? A very straightforward disabling of grapheme/word/line breaking would get us roughly 2x. That is without trying to be efficient about which Unicode tables we hit, etc.
Doing the same work through the context is ~30% slower, but might still be nice to have as a possibility in the API.
Pesky018mo agoAh, I was not paying close enough attention. Re‑tested with break masks: it helped, but still too slow per‑frame without caching. I now use a mono ASCII fast‑path and cache non‑ASCII to amortize it. Since the only path that hits kbts full breaking is amortized, for me the performance is fine actually.
I looked more into Blink, they use parallel iterators (script, emoji, orientation) and merge by earliest boundary. KBTS doesn’t have emoji/orientation I believe (?), but I can using the breaking api and manual runs to get this to work good for me (orientation is a non-problem and I don't care about emoji that much).
So I don't think I need the break masks since the cost is amortized anyways. Feel free to close this issue or keep it open :).
JimmyLefevre8mo agoIn kbts land, emojis are segmented just like any other grapheme cluster, and, depending on what you mean by "orientation", we do provide KBTS_BREAK_FLAG_DIRECTION.
If you have a specific use case in mind that seems like it would be generally useful, then maybe we could add a special-cased segmenter for it. Something like ASCII + emojis, for instance.
No fast path as of yet, but this isn't a bad idea.