From: Jens Arnold <arnold-j_at_t-online.de>
Date: Thu, 25 Aug 2005 20:16:27 +0200

Hallo ,

*** Weitergeleitete Nachricht, ursprünglich von Jens Arnold am 25.08.2005 ***

Hello Greg

On 25.08.2005, you wrote:

> : 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

It seems you didn't check current rockbox code. The current font
file format *is* pre-rotated for quite a while (almost exactly
one year now).
This has multiple advantages:

- Most font files are smaller
- faster loading
- less code. We're really tight on code space on archos now
- the builtin system font is read-only data, allowing to put it
  in ROM with rombox.

Basically we want the glyph bitmaps in the target's monochrome
bitmap format (which happens to be the same for all current
targets, but that may change, leading to different font files
per target).

> 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 think caching will be easy if we have memmove(), and I hope to
implement that one day (optimised of course). If a font doesn't
fit, the system could unload the lru font, move all subsequent
fonts in memory to close the gap, then load the new font.


Regards, Jens
*** Ende der weitergeleiteten Nachricht ***

MfG, Jens

-- 
-----------------------------------------
 eMail:  arnold-j_at_t-online.de
 WWW:    http://arnold-j.bei.t-online.de/
   _ //    .
   \X/   AMIGA - Creativity inside.
-----------------------------------------
_______________________________________________
http://cool.haxx.se/mailman/listinfo/rockbox

Received on 2005-08-25