Fast Math Rendering on the Web
bollu.github.io
bollu.github.io
You can render math statically with KaTeX and some standard static site-generator too. Here an example from my blog (using Pelican):
https://depot.traits.de/pages/2020/02/21-markdown-example.ht...
Instead of trying to come up with a compromise on rendering, a better idea might be simply not rendering your entire blog on one page... A plain HTML page with svg images weighing in at a shocking 2.6MB is not gonna load “instantly” anyhow. You can keep the source in a single markdown file if you wish, but there’s no reason you can’t split up the posts during processing, and that’s a much easier technical problem than this math rendering compromise.
> Far more importantly, it provides spatio-temporal locality. I add things in chronological order to tbe blog, as I learn thing. If I need to recall something I had studied, go to that location in the blog based on a sense of when. > When I do get to a location I want, the scrollbar gives me a sense of where I am in the file. this is important to me, since it hepls me reason spatially about what i know and what I've learnt. It's someting I love about books, and deeply miss when navigtaing the web.I'm determined to keep this spatio-temporal locality on my little slice of the internet.
And:
> I need a single file to edit, so I can rapidly jot down new ideas. This is the essence of why I'm able to log most of what I study: because it's seamless.
I really wish I _could_ get used to the usual way of doing things, but it just doesn't sit right with me, unfortunately.
I'd like to congratulate the author on building something like this. It obviously serves a niche, and represents an approach to that is useful.
That said, there is a trade-off to giving up beautiful math rendering. Aesthetics in math does matter for all but the roughest of jots -- even if you never show your jots to anyone.
When I was in academia, I kept my jots in a single continuous LaTeX file. I was fluent in LaTeX so I could jot down math almost faster than I could write them down on paper (keyboard + LaTeX macros + rapid copy-paste of repeated structures helped -- you wouldn't believe how much time you can save by making say "\sum_i^n\sum_j^m" a macro in index-heavy fields like mine).
I threw snippets and stuff into it, and because it was so beautiful, I would regularly review it and coalesce new ideas from it. Also, for the kind of math I was doing, I needed more symbols and structures than was supported, so I had to pull in packages. But the result was a set of notes that, for me, was pleasant to use. Render time? 3s on avg.
Good typeset is important, even if only psychologically.
https://mathml.igalia.com/ https://bugs.chromium.org/p/chromium/issues/detail?id=6606
As far as I can see Google aren't sponsoring this work (it's unclear to me why not), they've agreed it's worth doing and are reviewing patches.
> unfortunately, asking rust to treat UTF-8 string as a "ball of bytes" is hard, when it's stupidly easy with C.
String::as_bytes seems pretty easy, and there are byte literals b'?' of type u8 and b"???" of type [u8]. You can avoid interacting with the UTF-8 types at all if you don’t want to.
> Plus, I wanted to use arena-style-allocation where I make huge allocations in one go and then don't think about memory, something that I don't have control over in Rust.
Perhaps the bumpalo and typed-arena crates would interest you.
Specifically Chrome on Linux the GPU tile rendering is far slower than I can scroll, perhaps because some text blocks are large enough that the out-of-tile culling leaves too much work for each tile rendered?
Perhaps the custom font has something that really slows down rendering or something?
Which explains why they needed a better math rendering solution, although it raises numerous other questions.
Practically, if the draw culling algorithm is bad, rendering will get slow, which looks like it might be happening here.