Comment by kevingadd
1 year ago
Really a minor nitpick, but "It's as fast as plain text, because it is plain text" is definitely not true. Evaluating all these rules when shaping the text is not gonna be cheap, and if you overuse this type of font your end users' CPUs will probably be screaming. As would anyone who's implemented parts of the OpenType spec from scratch before. Worse still, this doesn't just impact rendering, since the output of shaping determines how big elements in the document are, so things like scrolling and window resizing and text selection can all lag.
Really fun to see a font that can do this though. Never would've expected it.
You are probably right, but I would like to see some actual benchmarks and tests. Unfortunately I didn't have time to do them myself yet, but I am curious what the difference between this, a basic font, and a highlighter script would be for a very large document.
It's definitely going to be significantly slower as a result of all the contextual lookups.
To get an idea, I repeatedly duplicated the CSS in the "tiny sandbox" until there were nearly 20,000 lines there, and then profiled the operation of changing the font-size by 1px in Firefox. Reflowing the textbox took about 1.6 seconds.
With `font-feature-settings: "calt" off` applied, so that the contextual lookups aren't being run, a font-size change for that same textbox content reflows in about 100 milliseconds.
(I don't have actual timings for the same example in Chrome, but subjectively, with "calt" disabled, the resize is near-instant, whereas with it enabled, it's quite laggy, similar to Firefox.)
In Firefox, 4000 lines of CSS: editing last lines is fast and instant, editing first lines is a bit jumpy refreshing every few edits in 0.2s-1.2s - however undo/redo is quite fast - but not so fast as with last lines, and.. from the first impression, guesses:
-= the highlight is always there, instantly =- (or.. it doesn't a look like a reason for jumpy lines because of redo) - definintly less cycles and memory overhead and I don't see that possible with DOM and JS - the delays could be there only because of inefficient editing operations with no impact of coloring.. and maybe with.. smaller textfragments (or ?) there could be no such delays at all - but simple* coloring coud be always so instant (and easy) ? (yes, I know, so far it may be also limiting and exclusive)