Unicode font bug?

[JetroPag]

I'm not sure if I'm at the right place, but this seemed like the right forum as this is clearly a font loading related problem.

Anyway, here's the problem:

I listen to Japanese music a lot and my id3 tags are written with unicode Japanese characters. I've noticed that every time Rockbox starts a new song it has to spin the disk to load the font to display the Japanese characters. This naturally eats the battery life considerably. If I use a regular font, there's no problem, but no Japanese characters either. :/

So, I was thinking that maybe the font loading could be performed at the same time as the buffer is filled. That way it wouldn't be necessary to spin the disk every time a new song is played.

in short:

1. I start listening to music
2. player fills buffer, plays one song, no problems
3. first song ends, a new one starts, disk spins for short time to load the font
4. correct japanese characters appear, song plays to the end
5. = 3.

So it loads only the font, this doesn't affect the song buffering.

My hardware:

iRiver H120 with the latest rockbox build from today (march 14.)
I use file mode with playlists. I don't like the database mode... ^^

I'd be very grateful if someone could come up with a fix for this problem. Thanks!

[Llorean]

There's a font cache. As time goes on, it'll be more familiar with what characters your song uses, and read from the disk less. The problem is that unifont is HUGE. We don't load the whole font into memory and keep it there, because that would have a negative effect on battery life *always*. Instead we basically load it when we need new characters, and then keep track of which ones get used, and keep a bunch of the most used ones around. This means that, the more you use your player, the more characters are cached, and so while it has to spin the disk up a bit more at the start, it should mean (for most people) better battery life over all.

[JetroPag]

Thanks for the reply!  So I guess I just have to bear with this "bug"... ?

Somehow I think however, that maybe it could be a good compromise to load the needed characters simultaneously with the buffer filling process. Just the characters for the songs that are buffered, not the whole font. That way there would be no need to spin the disk when the buffer is still filled. Well I don't know, just a thought.

Btw, I actually use a font I created myself, not the unifont as it's to large for my tastes.

Edit: I figured out a great way to stop the extra spinning.. I went to the database mode and scanned through all the songs. Now it has "memorized" all the characters. Problem solved for good,  yay.

[Lear]

There's actually a fix for this problem, but it is only used on the old Archos targets (sometimes called hwcodec targets). During buffering, the font cache is primed with the chars from the artist, album and title fields. Maybe it should be ported to the swcodec targets?