Not quite. A type renderer will cache the bitmaps for each individual letter so it only needs to calculate the vector to bitmap activity once for each individual glyph. This will also be the case if your SVG renders text as text (potentially with embedded fonts), but if it instead has that type as outlines then all the outlines need to be rendered and there’s no cache saving for typesetting, e.g., XXX
> A type renderer will cache the bitmaps for each individual letter so it only needs to calculate the vector to bitmap activity once for each individual glyph
you mean subpixel antialiasing. but yes, as it turns out, type renderers do cache subpixel-antialiased pixmaps. the part where this gets tricky is with subpixel positioning of the antialiased letterforms, but you can cache them in that case too if you quantize the positioning, even if you don't quantize it to entire pixels
Perhaps but on my phone I can zoom in and out real fast on a page of text without a single glitch or hiccup and there’s no way a >512px bitmap for every character displayed is used.
If you were to do a slow motion video of what’s happening, what you would see is that it’s the bitmap that’s zoomed and then the zoomed bitmap gets replaced with a rendering of the outlines. It is not re-rendering outlines at every zoom level.
Vector graphics were avoided on the Web because they made pages perform poorly. The advice was widespread, and it was easy to see why if you did encounter an SVG on the Web.
We couldn’t draw with CSS yet, but in the earliest days of that being possible, it was slow, too.
Moore’s law outran those problems, but I suspect our collectively dropping the old “raster = considerate to your user” attitude (including and especially in what we do with CSS these days) is an under-appreciated factor in the astonishingly terrible performance of the modern Web—Javascript gets most of the blame, but I think a lot of it’s giant CSS engines and doing so very much more runtime rendering on the client.