This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#11064 - Resizable skin buffer
Attached to Project:
Rockbox
Opened by Thomas Martitz (kugel.) - Saturday, 27 February 2010, 19:16 GMT+2
Last edited by Thomas Martitz (kugel.) - Thursday, 22 December 2011, 16:49 GMT+2
Opened by Thomas Martitz (kugel.) - Saturday, 27 February 2010, 19:16 GMT+2
Last edited by Thomas Martitz (kugel.) - Thursday, 22 December 2011, 16:49 GMT+2
|
DetailsThis patch modifies skin loading and buffering so that it enables resizing of the skin buffer.
Skin parsing happens in 2 passes now. - the first pass parses everything but fonts and images (i.e. everything that fits into a sane backup buffer) - the second pass loads the bitmaps and fonts (the filenames are saved, so the second pass doesn't mean reparsing) Upon parsing, the first pass reports the size needed. if it exceeds the existing buffer it asks for a reboot. in any event, it will drop a .skin_engine_%d file where %d has the size needed. Upon reboot, the skin buffer will use this for its size. A 10k backup buffer is always added. This is all complicated because of the skin buffer architecture (bidirectional) but seems to work. 2 issues: - backdrop handling is a bit stupid right now, it will assume loading one even if the skin reuses an already buffered one. that's not a big issue as it will be right after the next reboot (the parsing at boot dumps the real size, not the one reported by the first pass). - everything is pretty messed up if the buffer wasn't enough, like corrupted images etc. this needs better handling. 
resizable_skin_buffer.diff
(26.7 KiB)
b/apps/gui/skin_engine/skin_buffer.c | 63 +++++++++++++- b/apps/gui/skin_engine/skin_buffer.h | 4 b/apps/gui/skin_engine/skin_engine.h | 5 - b/apps/gui/skin_engine/skin_fonts.c | 5 - b/apps/gui/skin_engine/skin_fonts.h | 3 b/apps/gui/skin_engine/skin_parser.c | 148 ++++++++++++++++++++++++++--------- b/apps/gui/statusbar-skinned.c | 109 +++++++++++++------------ b/apps/gui/statusbar-skinned.h | 8 - b/apps/gui/theme_settings.c | 58 +++++++++++-- b/apps/gui/wps.c | 17 +++- b/apps/gui/wps.h | 3 11 files changed, 307 insertions(+), 116 deletions(-) |
This task depends upon
Closed by Thomas Martitz (kugel.)
Thursday, 22 December 2011, 16:49 GMT+2
Reason for closing: Out of Date
Additional comments about closing: The skin buffer is dynamic via buflib now.
Thursday, 22 December 2011, 16:49 GMT+2
Reason for closing: Out of Date
Additional comments about closing: The skin buffer is dynamic via buflib now.
Also quit your belly aching about the buffer mechanism, it works quite well and complaining just annoys people. (and if you really care that much then change the tokens array to a linked list, use offsets instead of pointers everywhere, and make the bmp loader smarter so it knows how much it reauires t load a bmp)
why do you add 20K to the known size? that seems way too high, it should be screen depth dependant, 2K is probblay enough for non colour.
theme loading is noticably slower (even with a CF disk), but its worth it :) looking good
remove the commented out code and extra unneeded comments.
the reboot splash isnt good enough, if it fails it really should reload the inbuilt skins (otherwise rockbox will crash on entering the WPS), and the timeout on that splash should be more than 1 second.
skin_buffer_dump_size() should be named something else, and the comments attached to it are incorrect.
edit: the SKIN_BUFFER_SIZE should be increased by at least 1xSKIN_FONT_SIZE, probably more so there is a very high chance that any theme loaded without nvram.bin will load first go (I tihnk though for this reason that the theme size should be in the .cfg and not nvram.bin
The function name was correct when I used the extra file, but it can be renamed of course.
The 20k buffer is to ensure that at least all tokens fit into it (i.e. ensure that the first pass succeeds). Imagine someone goes from a simple text only wps (only few kB big) to a more complex one. In this scenario the first pass could fail without a bigger backup buffer. And if the first pass fails there's no way of knowing the size for the second pass. It doesn't need to be display depth dependent since it's not for images.
I'm disagreeing with the size in the .cfg idea. people shouldn't be able to mess with it.