Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: Thoughts on Multiple Fonts in Rockbox

Re: Thoughts on Multiple Fonts in Rockbox

From: Greg Haerr <greg_at_censoft.com>
Date: 2005-08-25

: We use a fixed size static memory area for loaded fonts. That's the cache.
We
: can load N fonts into the cache and thus we can use at most N different
fonts
: simultaneously on a single screen.
:
: N can differ depending on the actual target model, just depending on how
much
: memory we want to provide/waste for fonts.
:
: If an application selects to display a font that isn't in the cache
already,
: it loads that font (and possibly flushes an old one from it).
:
: Thus, we can support displaying of numerous fonts, while we only support N
: simultaneous ones. In most screens you only use a single font anyway. The
only
: downside is that the selecting of a font that isn't in the cache requires
a
: disk spin-up and load.

For N = 2, things are simple. For N > 2, the biggest issue will
be the complexity of the memory management desired. The font
files aren't quite in read-only format, so it takes time to load a font,
other than just reading disk. (this could be lessened by moving to
a read-only font file format w/pre-rotation, although table offsets
still have to be calced). The easiest implementation essentially
discards a font and re-uses the same "open" code to (re)load
a font that's required, rather than using special additional code
to reload a font. In this way, only the mem location to put
the font is problematic.

: I would imagine that we could have the font changing function have a
parameter
: that asks for the specified font mandatory or optionally, and in the
latter
: case we could have a fancy way for the font subsystem to pick the one of
the
: already loaded fonts that is most similar to the one you ask for.

The system always tries to get the font, otherwise, it downgrades
and returns a default font instead. We probably don't need the
mandatory or optional functionality. My take would be that
the config file format would completely specify an application
font use with a font filename. Then, when the application requests
its font, the config mapping is always used unless the font file is
missing, in which case the default font number is returned.

In this way the application doesn't have to go through "open"
routines with fonts, it just uses application-specific FONT_xxx
values, which the config file parser knows about (and has already
parsed). The application would "request" a font for drawing,
which would return a system font id from the passed application
font id, useful just for the duration of the application drawing
(but cached by the lower level).

Regards,

Greg

_______________________________________________
http://cool.haxx.se/mailman/listinfo/rockbox
Received on Thu Aug 25 19:37:37 2005


Page was last modified "Jan 10 2012" The Rockbox Crew
aaa