On Tue, Oct 28, 2008 at 6:40 PM, Thomas Martitz <[EMAIL PROTECTED]> wrote:
> I pretty much agree with XavierGr in this discussion. Devs tend to evaluate
> new features only on their own using habbits. More then often binsize seems

and people doing patches aren't doing them based on their habits? Do
users judging patches don't do this based on their taste and possibly
usage habits from other areas? Isn't in reality anyone kinda bound by
its habits?

> I don't say binsize isn't a valid reason. But it's kinda stressed very much

Maybe it's stressed much lately. But as already has been said, Rockbox
is much more "feature complete" than it was like two years ago, and we
need to decide how much bells and whistles we really want and what
(and especially how much space) we're willing to sacrifice for this. I
haven't seen much of a discussion about this here though.

> We then could possibly just have a features setting menu, where you can
> chose from several features to be enabled or disabled. This way, unused
> features could free most of the RAM they "waste" reducing the ram usage

Rockbox uses almost exclusively static buffers. How should disabling
features change the required RAM? Features that can free memory if
unused already do this (at the cost of requiring a reboot after
changing). Perhaps there are settings that don't do this yet but could
easily be adapted. Of course it needs to get decided if the possible
issues such a change might bring up is worth it. Still, for most cases
this is not possible. Otherwise we would need to make Rockbox use
"real" dynamic memory, and this is something that is definitely not
wanted.


 - Dominik

Reply via email to