Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#12333 - Faster cached font loading

Attached to Project: Rockbox
Opened by Fred Bauer (freddyb) - Friday, 14 October 2011, 05:14 GMT+2
Last edited by Fred Bauer (freddyb) - Monday, 17 October 2011, 17:48 GMT+2
Task Type Patches
Category Font/charset
Status Closed
Assigned To No-one
Player Type All players
Severity Low
Priority Low
Reported Version Release 3.9
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Private No

Details

When font glyphs are loaded from disk there are 3 file sections to read from: width data, offset data, and bitmap data. The number of disk seeks can be very much reduced by opening the font file with three separate file descriptors, each of which have a small cache. This is a small patch that opens additional file descriptors for width and offset data during glyph_cache_load(). The fd's are closed after the initial load so it only uses two extra fd's for a short time. It's a bit of a kludge but it increases initial glyph loading speed about 600% for a cached font.
   fast_preload.patch (2.8 KiB) 
 firmware/export/font.h |    2 ++
 firmware/font.c        |   34 +++++++++++++++++++++++++++-------
 2 files changed, 29 insertions(+), 7 deletions(-)

This task depends upon

Closed by  Fred Bauer (freddyb)
Monday, 17 October 2011, 17:48 GMT+2
Reason for closing:  Accepted
Additional comments about closing:  in 30769.
Comment by Fred Bauer (freddyb) - Saturday, 15 October 2011, 00:10 GMT+2
Resync to SVN.
Update convbdf.c c source generation to include extra structure members.
   fast_preload.2.patch (3.9 KiB) 
 tools/convbdf.c            |    2 ++
 apps/recorder/pcm_record.c |    1 +
 firmware/export/font.h     |    2 ++
 firmware/font.c            |   33 ++++++++++++++++++++++++++++-----
 4 files changed, 33 insertions(+), 5 deletions(-)

Comment by Thomas Martitz (kugel.) - Saturday, 15 October 2011, 14:15 GMT+2
I'm not sure I understand this patch correctly.

- Does this change the font structure in a way that existing fonts are incompatible?
- Is lseek() that bad? I thought it was bad if the underlying disk needs to actually seek. I don't see how multple FDs can help the disk there. Also you don't actually reduce lseek() calls do you?
Comment by Fred Bauer (freddyb) - Saturday, 15 October 2011, 23:25 GMT+2
Lseek() can be cheap or expensive depending on if the seek is outside of the cache.
When a font loads a glyph it does the following:
1) reads 1 byte from the width section of the file
2) reads 2-4 bytes from the offset section of the file
3) reads the bitmap data pointed to by the offset
4)...next glyph
The default font preload without a .glyphcache file is to load 224 glyphs and some fonts are spread over 100,000's of bytes. The seeks are mostly cache misses because the read locations are round-robin.
Opening separate file handles for width, offset, and bitmap data gives you a small amount of cache for each section so that width and offset data would only be lseeked a few times as each seek/read is hitting the same cache repeatedly. It's not about having multiple fd's, but having three caches.

The font files do not change.

Comment by Fred Bauer (freddyb) - Monday, 17 October 2011, 04:01 GMT+2
Resynced and simplified glyph_cache_load() by removing some of the old glyph presorting code which will no longer be necessary.
   fast_preload.4.patch (6.1 KiB) 
 tools/convbdf.c        |    2 +
 firmware/export/font.h |    2 +
 firmware/font.c        |   91 +++++++++++++++++++++----------------------------
 3 files changed, 43 insertions(+), 52 deletions(-)

Loading...