[ben-schaaf]

The alternative is that for every glyph you render the entire glyph to the screen using the Bezier curves from the font, and you end up with dogshit performance - like the new windows terminal (not sure if they've fixed it yet).

Caching glyphs is good resource management and with modern screen resolutions, color displays and subpixel-antialiasing you just simply need more than 70KB of RAM.

[littlestymaar]

> The alternative is that for every glyph you render the entire glyph to the screen using the Bezier curves from the font

No, because you have no reason to have much more glyphs in your font cache than what fits your screen either (for people using a language with an alphabet based on the latin one at least, which is the majority of people on this website).

> you just simply need more than 70KB of RAM.

I didn't set the bar to 70kB. You also need more than 70kB of RAM yo store a full screen worth of image (which was the bar I set above).

But that doesn't mean you need 1GB either.

[ben-schaaf]

> I didn't set the bar to 70kB

The GP to your original did set the bar at 70kB, mattmanser then explained that images and fonts easily exceed that, and then you called that poor resource management. Sounds like we're on the same page here, but you seemed to have missed the context of the comment you initially replied to.

[littlestymaar]

> The GP to your original did set the bar at 70kB

It didn't, here's the comment in question:

> A probe collecting data in space takes <70 kB of memory. I fail to see how this statement should make me feel happy

It makes no mention that an app should be under 70kB. It just note that 100MB is still *enormous* compared to 70kB.

And I maintain that the difference cannot be explained by images and font cache alone.

[ben-schaaf]

> And I maintain that the difference cannot be explained by images and font cache alone.

It can't be explained by images and fonts alone, I agree, but images and fonts alone are still enormous compared to 70kB. On my screen an "e" on this site is 10*11 pixels. Subpixel positioning means we need at least 6 copies of each letter, subpixel antialiasing means we need three channel alpha (3 bytes per pixel), we have variations of bold, italic and bold-italic, 95 printable letters in ascii, that's a low-ball of 750kB for one size of one font. This comment page alone has 4 different sizes, I'd expect a chat app to have a few more.

[littlestymaar]

Well even with your quite conservative calculations [1] you end up with a size that is absolutely reasonable and negligible in a 100MB footprint.

[1]: Realistically, you're never gonna have all 95 characters in all weights for all font size, so the actual number is going to much significantly lower than the theoretical envelope. In practice, there'll be a main (font,size), that will have all glyphs (and it's going to be more than 95 because of the ligatures) in normal weight and no italic, with a subset of the glyphs in the three other modes, most likely not evenly distributed between modes. Then you'll have additional fonts (for UI labels, titles, etc) that are going to have much less represented glyphs and almost no variations of weight or italic if at all. Obviously the font(s) used for titles in going to have a bigger budget relatively to the glyph sample size, because each one is bigger than your baseline "e"