Rockbox mail archiveSubject: 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 <jdgordy_at_gmail.com>
Date: Thu, 24 Dec 2009 00:14:03 -0800
2009/12/21 Jonathan Gordon <jdgordy_at_gmail.com>:
> 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
> 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
> 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
> 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?
Well, I'm pretty much done with my rockbox time untill the middle of
January so this is going to have a break, but in the hope of easying
some peoples minds and making sure I dont forget, this is where I
would really have liked the theme stuff to end up:
- 1 shared buffer for all theme elements (skins and backdrops, *maybe*
icons but probably not)
- removal of colour, backdrop and ui viewport settings, replaced with
users being forced to use a sbs, which really isnt such a bad thing,
especially if the current UI is fixed to work from the .sbs instead of
the settings. Of course this only affects people who dont use themes,
and in that case I really can't imagine they change these settings
more than once a day, or even week...
- the backdrop for the menus comes from the sbs, if the theme is
enabled then that backdrop is always used. This means you cant enable
the theme in the WPS and show a different backdrop (which imo doesn't
make sense anyway)
- theme loading would parse all the skins before loading any bitmaps,
this way we can know fairly accurately how much buffer is required, if
not enough is allocated we can splash a "reboot to enable" or a yes/no
to cancel loading the theme, or ask to reboot immediately.
If someone can come up with a nice way (i.e other than storing a copy
of the global_settings.fgcolour in the lcd driver) to update all skin
viewports with the new setting (without reloading the entire theme)
then I'm all ears. This is actually a pretty old bug that goes back to
before ui viewport and sbs stuff... if you load a WPS with the colours
for any viewport set to - (so it gets it from the settings), then
change the setting, the viewport will show the wrong colour. This
never came up because its simply not something that normally happens,
which is why I have no qualms about removing the setting entirely.
IIRC kugels origional sbs patch got around this issue (only for the
%vi token) by always grabbing the setting, which is wrong, because a)
the user might not want that, b) the ui viewport isnt the only one
which needs to be kept in sync with the setting.
Something else to think about is how can we add a sort of variables
system to the skin code? it would be very nice if we could set some
variables at the top of the skin and then use them later on... e.g
%_a|aabbcc <- set the variable 'a' to the text aabbcc, then in a
viewport definition it would look like %V|0|0|100|100|1|%_a|%_b so
users could very easily change the colour everywhere.... The very
simple solution is only allowing the fore/background colours to do
this (2 new tokens or something), then the viewport definition would
continue to use '-' for the colours, which would solve this problem,
but it would only work in that one spot. It would be really great if
we could do even more with it, setting a viewports position for
anyway, enough brain fart from me!
Received on 2009-12-24