This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#10984 - multifont
Attached to Project:
Rockbox
Opened by Jonathan Gordon (jdgordon) - Tuesday, 09 February 2010, 08:43 GMT+2
Last edited by Jonathan Gordon (jdgordon) - Sunday, 14 February 2010, 07:39 GMT+2
Opened by Jonathan Gordon (jdgordon) - Tuesday, 09 February 2010, 08:43 GMT+2
Last edited by Jonathan Gordon (jdgordon) - Sunday, 14 February 2010, 07:39 GMT+2
|
DetailsThis patch aims to add multifont to the core in a workable solution.
this is the plan: 1) remove all the local variables (apart from the absolute necessary) from font.c so it can be more usable 2) change font.c to handle more than one ui font, only a single ui font structure will be statically allocated, any others need to pass in their own font struct and buffer 3) fix skins to be able to request a font be loaded and usable in viewports. 3.1) make the apps/ level font API be simple so plugins can use it also. NOTE: there is no plan at all to allow anything except skins in the core to use more than 1 ui font. this first version does part 1. 2 |
This task depends upon
Closed by Jonathan Gordon (jdgordon)
Sunday, 14 February 2010, 07:39 GMT+2
Reason for closing: Accepted
Additional comments about closing: r 24644.
Sunday, 14 February 2010, 07:39 GMT+2
Reason for closing: Accepted
Additional comments about closing: r 24644.
- fix the .glyphcache files so each font name gets its own (this does no collision handling, so if you try to load a font twice it will break... DONT do that :p
- remove all the struct font* pf = &font_ui; lines so it is safe to pass a pf around.
- changed font_load() to return the font number instead of the font struct (seen as the return value is never actually used this makes sense)
I need to fix up the MAXFONTS and MAXUSERFONTS names, and work out where we want to make sure we dont load the same font twice. I oribionally planned on having a reference counter (so skins wont try unloading a font if another theme still uses it) in the apps level API which would make the most sense, except the problem with fontcache collisions, if that is actually a problem? (I tihnk it is, but I'm half asleep)
This is just one thing I've spotted. I haven't looked very deeply into it :-P
anywho, lets get back to the patch discussion.
I have no idea how to do the setting for it though because the regular font setting is changed by just loading a .fnt. maybe a context menu item on .fnts?
if you want to test this add a "remote font: /.rockbox/fonts/my-font.fnt" line to your config
just need to figure out what to do about the glyphcache file(s) and plugins.
also change back to a sensible cacheing mechanism. only the FONT_UI font glyphs are cached. all fonts when loaded read that glyphcache file and it stands to reason that most of the same glyphs will be used in skin fonts as the main font, and the main and remote font will always show the same.
edit: I'd be happy to see this version commited. the only thing missing is plugin support which could wait, or even be ignored imo.
1. The plugin API version(s) should be bumped
2. What is the "buffer" field in the struct skin_font for?
3. I see the buffer allocation for a font (from the skin) but no release. Is it OK?
4. What is "first_init" in skin_font_init for?
5. The skin functions need at least a brief comment
6. I'd rename the variable "mbuf" to "main_buf" or similar in font.c, to be more in line with "remote_buf"
2) that is to allow things to replace the loaded font without takeing more buffer. mostly goign to be used by the plugins once the api for them is done (I'm not too worried about not doing that in the first version though. it can come after)
3) you cant release the buffers from the skin buffer block, this goes with point 2 a bit. When a new theme is loaded all the fonts are blown away anyway so the ram is freed then.
4) should be remoavable now. it was there to unload fonts and save their cache files, but seen as only the main lcd's ui font is cached this is not needed.
5) yeah yeah :)
6) ok