Font rendering optimisations

A couple of weeks ago while tweaking some code I found myself looking at the font rendering code in the font manager. I made a few simple performance tweaks straight away, but I think there’s still a lot of room for improvement. I’m not expecting to find the time to look into this myself any time soon, so I thought I’d throw it out there for any other interested parties:

• First of all there’s the blended font rendering code, in Manager.s.Blending. If you look at how and where the “Blend” macro is used then you’ll see that it loads the font pixel (an alpha value from 0-16), loads the screen pixel, and then uses Blend three times to blend the R/G/B components of the screen pixel with the current font colour. This is a total of 6 multiplies/MLAs.
  • Although I’ve made some simple optimisations here to cut down on the amount of work the blend macro does, it should be possible to make things faster still by making use of parallel multiplication, as discussed here.
  • Unfortunately since the alpha value changes on a per-pixel basis you’ll be limited in terms of how much you’ll be able to do in one go. I think that for 8/16bpp blending you might be able to get it down to two multiplies (R+G+B in parallel), whereas 32bpp will be stuck with four (R+B in parallel, G handled seperately)
  • By getting rid of the seperate Blend invocations it may also be possible to make some improvements to the instruction scheduling
  • It may also be worth investigating the performance gain/loss from precalculating the 16 different levels of font colour and storing it in a palette instead of recalculating it on a per-pixel basis. This would cut the number of multiplies in half.
• Secondly there’s the regular font rendering code, in Manager.s.Fonts02 (look for the “quickclip” routine, for plotting of untransformed, unclipped characters). While testing to see how much of a performance improvement my blended font changes made, I noticed a strange thing on my Iyonix – regular font rendering was actually slower than blended font rendering! After locating the regular font rendering code it was clear what the problem was – it was designed for low bit depth modes, and doesn’t seem to have been updated for high bit depth modes or systems where screen reads are slow.
  • If you look at “indatalp” then you’ll see an example of Duff’s device. Each invocation of the “Pixel” macro processes one pixel out of the 8 pixels in the loaded word of the font image, and the correct part of the loop is branched into depending on where within the word processing should start.
  • Inside the Pixel macro you’ll spot the “ORRS outdata,R14,outdata LSR bpp” line, followed by “BLCS putdata”. This inserts each pixel into the output word and then branches out once the word is full (‘outdata’ is initialised to &80000000, so once the right number of pixels have been processed that top bit will be shifted out and cause the carry flag to be set). Except in 32bpp modes this will happen after each and every pixel. So one optimisation for 32bpp modes would be to introduce a second version of the loop which avoids the need to branch out to write each pixel, as well as allow you to get rid of all the pointless shifting of outdata/outmask (since you know it’ll only be one pixel in each register)
  • To make things worse, the putdata routine seems to blend the data with the screen, regardless of whether (a) something needs to be rendered (i.e. outmask not &0), and (b) whether any blending is required (i.e. outmask not &ffffffff). For low-colour modes this is probably OK, as most words of data are likely to require blending. But for 32bpp you’ll either be in the situation where the entire pixel needs to be replaced, or the entire pixel needs to be left alone – so you can avoid the screen read entirely (which would be slooow on Iyonix), and in quite a few cases avoid the screen write too (which would also be a bit slow). It might be possible to tweak things for 16bpp too, since you’re more likely to find yourself in the situation where the screen read/write can be skipped compared to 8/4/2/1bpp modes.
• Bonus points if you can find a way to make things faster by using NEON. But for the time being I think focusing on making font rendering on the Iyonix faster would be a more worthwhile goal, because the current code is quite shockingly poor.

Have fun!

Top of my list for font manager improvements by a long long way would be for Font_Paint to display and Font_ScanString to measure the ‘Replacement character code’ (unicode &FFFD) when using a font/encoding that doesn’t have a glyph for the character. e.g. if a font doesn’t have an ‘A’ then character code 65 in a string displays the replacement character code glyph which, according to wikipedia, is often a white question mark in a black diamond.

Before anybody spends too much time looking at Fonts02 rendering optimisations, I have a confession. I’ve been sitting on ix-directed performance optimisations such as Jeffrey’s suggested suppression of needless screen access for some time. I’ll feed them back to ROOL along with the R-Pi work, for the – belated – benefit of other builds too.

I’d had a thought before Adrian’s posting which probably makes it reduntant and I could well have got the wrong end of the stick anyway, but I’ll mention just in case:
Most font blending in a particular window will have text in only one colour (normally black) and have one colour of background (normally white) could a table be created and then looked up if the text colour/background colour combination already had a table?

That’s basically what the non-blended font code does already. You specify the font foreground and background colours and then it produces a 16 entry palette/lookup table for blending the font against that background. Any well-written program should hopefully be smart enough to disable font blending whenever it knows it’s plotting against a specific background colour.

For 16bpp and 32bpp font blending I don’t think using lookup tables would help at all (except perhaps for precomputing the 16 levels of font colour). Full blending tables would simply be too big to be worth computing.

For 8bpp blended fonts the code currently uses a lookup table to convert each pixel to 16bpp, blends that, and then uses another lookup table to convert back to 8bpp. This could be made a lot faster if it was changed to use just one lookup table that blends against a specific font colour. The only trouble is it would need recalculating each time the font colour changes, so to avoid rebuilding tables too often you might need to store tables for the N most recently used colours (Each table would have 4096 entries, so building a lookup table would be roughly equivalent to plotting 4096 pixels using the old code).

I should have guessed it was more complicated than I thought. Thanks for the explanation.

The non-blended font rendering optimisations by Adrian have now been added .