|
Rockbox mail archiveSubject: 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 |