Tiny RISC OS factoid of no importance. A #RISCOS thread.
“Font blending is expensive” it has been said. Well yes, it is, when you do it as badly as FontManager does (e.g. in 32K modes it uses 6 times more multiplies per pixel than it could).
It’s especially bad in 256 colour modes (I know you don’t care but there’s a principle here).
Because in 8bpp it uses 24 multiplies per word, when it could use...
None.
In fact it loads a screen pixel, then indexes the palette colour, then does six multiplies, then indexes a quantisation table, then stores the new pixel – for every pixel it blends.
Not expert code.
Instead it could do this: Load screen pixel, index a table, store the new pixel.
Here’s some 100% Basic doing alpha blending (AND the necessary table calculation) in real time to demonstrate how efficient it is – doing this with multiplies would be dog slow.
“Ah, but how big is this table?”
The current code accesses a 1KB palette then a 32KB quantisation table.
Whereas this technique uses 4KB in total.
The table must be recalculated when the text colour changes, but 4KB is trivial to cache and in practice there’s black and... :elmoshrug:
[That Basic demo is calculating the table between each colour, so it’s CHEAP]
Anyway, not especially important, but interesting. And slightly depressing that I only just thought of it.
nemo 🐦 🟦 🐳 🃏 🥚