Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide
translations



Rockbox mail archive

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

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

From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Mon, 21 Dec 2009 11:36:08 -0800

Here is the current themeing situation:
a "theme" consists of one or more of the following items:
- a WPS (which can load a backdrop)
- a statusbar (SBS or inbuilt)
- a ui viewport setting
- a backdrop setting
- fore/background colours
- selected line colour/gradient
- an icon set
- font

And at the very least, will include (eventually) a skin for the fm
screen and the recording screen (both of which shuold be able to load
a backdrop).

Now, there are a few bugs with all this, for example, if you change
the back/fore ground colours manually they will take no effect because
the ui viewport has already been loaded or outright ignores the
setting.
What I really want to do is get rid of the colour, ui viewport and
backdrop settings and have them loaded from the sbs. I argued from the
very beginning that once the sbs was in the ui viewport setting was
totally redundant, as are the colour and backdrop settings.

Once thats done it makes sense that any screen which enables the theme
follows the sbs's layout (with the backdrop if loaded), and any
screens that disable the theme are going to use the fullscreen so are
expecting a blank screen (no ui viewport, no sbs, no backdrop).

so far so good?

Now, in svn there is RAM allocated for 2 backdrop images, whether they
are loaded or not, that RAM is being used. with only 2 images thats
acceptable, but what happens when a theme wants a different backdrop
for each of the 4 (currently expected) skins? (i.e sbs, wps, fms,
wrs)? each of those needs a ~95KB buffer (for the 176x220 pixel
targets anyway), which is hardly a insignificant number. Couple that
with the requirement to allow more room for images also (right now its
not such a problem, but when there are 4 fully skinable screens, its
getting big... ~93KB are allocated for images and tokens on the e200
currently)
Wasting lots of RAM to make it pretty is going to be fine for some
people, but totally unacceptable for others so we have to find some
middle ground for this.

This is where it starts to get tricky... If we move as much as we can
(i.e everything) into a preallocated (but user configurable somehow)
buffer, we need to handle themes which are too big for the current
size).

Without putting in a stupidly complicated system, what I would like to
do is simply have a setting "Maximum theme size" with values "tiny (no
images), small (no backdrops), medium (2 full screens), large (3 full
screens), massive (5 full screens)." That would be used to specify
what the largest theme size to load would be. If the user tries to
load one larger it would error out. Because we know exactly how much
of that buffer is actually used, we can save that in the theme file so
we can warn the user even before loading any parts of the theme that
it wont fit.

This is inevitably going to load to the question "Can the skin be
compacted and moved in the buffer to recover the wasted space after
load?" and the answer is NO. There is just way too much use of
pointers that its a massive rework to change that.

Right thats enough...

So recapping.. the discussion is:
1) can we get rid of the redundant settings (forground/background
colour, backdrop, ui viewport, etc)
2) can we come up with a workable solution to make the skin buffer
user configurable?

Jonathan
Received on 2009-12-21

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