dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re: themes, skins, backdrops and RAM usage... (i.e sure to be controversial)

Re: themes, skins, backdrops and RAM usage... (i.e sure to be controversial)

From: Jonathan Gordon <>
Date: Tue, 22 Dec 2009 11:35:28 -0800

2009/12/22 Thomas Martitz <>:
> Am 22.12.2009 20:05, schrieb Jonathan Gordon:
>> loading the theme first into the plugin buffer means loading and
>> parsing it twice, like I said before, there is just way too much
>> pointer use to copy the whole buffer or resize it once its loaded the
>> first time. We can't use the audio buffer for this, because doing that
>> would mean wasting a massive amount each time a new theme is loaded
>> (remember, there is no way to restore ram to the audio buffer.
> It has been suggested to just leave the already allocated buffer if the skin
> fits. After the next reboot it will be allocated correctly. I think that's a
> fine trade-off.
> Parsing twice shouldn't be a problem, since that's already quite fast. And
> skipping the loading of bitmaps will make the first pass even faster.
> Considering that this only happens during theme changing, not repeatedly, it
> doesn't appear to be a problem. The pointer stuff wouldn't be needed as
> well; the buffer could just be trashed after the first pass. Doing that only
> means that skins can't be loaded separately, but rather like the first pass
> for each skin, then the second pass for each skin.
> In the end it would be a major gain for people that don't change theme too
> often and for those using minimal themes.
> Best regards.

If you don't change your theme often (or ever) then a much simpler
system makes so much more sense. Also, have you thought about how this
2 pass system would work? all skins share a common buffer, which means
you need to do the first pass of every skin, then dump the buffer and
do the 2nd pass of every skin again which is slow and wasteful.
right now on the e200 93KB + 2x98KB buffers are preallocated whether
they are used or not. even cabbie only uses about 20KB of the first
buffer, which means that anyone not using themes would regain at the
best case nearly 300KB of audio buffer if a simple
"tiny/low/medium/high/stupid" setting is used, and that guarantees
that during a session, you cannot run out of memory which your and
pondlifes suggestion would allow.

We already can know if a theme doesn't fit simply by the parser
returning an error when it runs out of room, loading the bmp
dimensions beforehand doesn't make things any simpler, reallocating
buffer is not a good idea.
Received on 2009-12-22

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy