Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
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: Matthias Mohr <Matthias_at_mohrenclan.de>
Date: Tue, 22 Dec 2009 12:18:33 +0100

Hi everybody,

> - the ability to set colours to work on the fly (i.e. as it always did, most
> useful for actually seeing the colour/readability on target. A reboot, or
> text file editing, should not be part of this)
I absolutely second that!
Users will not understand why they need to reboot or edit a text file for such
a "simple" task as changing colours...

And the ability to dynamically use the colour settings of the menu in a
viewport by using "-" as colour should absolutely be kept (and fixed!)
That allows the use of user colour preference in themes.

> - As much RAM as possible for the audio buffer (i.e. a setting to reduce any
> static allocation, assuming the setting itself doesn't eat much RAM!).
Playing audio files is the main reason for using an audio player so of course
it should always take precedence!
If there's enough RAM for the audio buffer to play the files without problem -
the remainder may be used for other things...

But I also think that the user should NOT define such buffer sizes.
Normally he doesn't care about such "internal" things.
Either the user doesn't use big themes so he wants as much RAM as possible for
his playback.
Or he wants nice looking and uses big themes - but still don't care about any
buffer sizes.
So for me themes should be able to use automatically correct buffer sizes.
Even if only a few sizes are possible (e.g. small, medium, large, very large).
E.g. you could make parsing a two-way process and only detect the memory needs
(small, medium, large, very large) in the first pass.
The first pass could be done when the user selects a new theme or the themes
could define which size they need.
If the new size match the previous one (e.g. still "medium") it could keep the
current buffer size;
if the new one needs less size (e.g. previous "medium", now "small") it could
define the new buffer size but still use the current one; the new size will be
set and used after next reboot.
if the new one needs more space (e.g. previous "medium", now "large") it could
define the new buffer size and tell the user to reboot the device.

BTW, I'm not so familar with the possibilities for memory usage, but I don't
think statically defined buffer sizes are good (they're always either to small
or to big).

my 2cents,
Massa
Received on 2009-12-22


Page was last modified "Jan 10 2012" The Rockbox Crew
aaa