|
Rockbox mail archiveSubject: HWCODECHWCODEC
From: Mike Giacomelli <giac2000_at_hotmail.com>
Date: Wed, 14 Dec 2011 18:21:42 -0500 Hi everyone. Over the last couple months there has been some discussion about what to do with HWCODEC following dreamlayer's forum thread. During this discussion, several developers still using HWCODEC mentioned that they preferred/recommended older builds over newer releases. The general opinion seemed to be that somewhere around 2.x-3.0 HWCODEC peaked. Over the years we've discussed the possibility of forking off HWCODEC and decided that there are serious advantages and drawbacks to doing so. I'll list the ones that I remember (but I'm sure I'll forget some). Advantages: ***Greatly simplify large parts of the code for SWCODEC targets (see JdGordon's forum posts in rockbox general) ***Enable us to arrest and hopefully reverse the slow bin size increases that are squeezing HWCODEC to death by simplifying bits of rockbox that are simply too awkward to do with ifdefs. ***Prevent developers unfamiliar with HWCODEC from breaking it. Disadvantages: ***Only a few people are working on HWCODEC, so if we did fork it, would it just continue to rot? ***Duplication of effort for fixes in common code ***HWCODEC is useful because it reminds us to avoid needlessly bloating file size (although this is probably no longer true since we have SWCODEC targets with more memory constraints) Over the years I think the advantages have become more appealing because its becoming harder and harder to keep binsize small enough to fit into some HWCODEC targets. While at the same time, we've got low memory SWCODEC targets that are arguably more constrained by total RAM (e.g. the c200v2 with 2.3MB of RAM for SWCODEC and a color display) then the Archos Player. I think we should consider branching into rockbox and rockbox-classic branches at some convenient point in the future. When we do, I propose that we would leave SWCODEC in the classic branch and setup the build system to compile a representative subset of those devices. From then on new features would focus on HWCODEC, and if someone is interested they would be free to pare back features like theming that consume binary space without being terribly useful on charcell devices. The non-classic branch would depreciate HWCODEC support. We would remove HWCODEC devices from the build system and gradually begin removing it from the code organically as various parts of rockbox are improved/refactored/rewritten. So in effect we would have one branch that gradually became SWCODEC only, and another branch that retained both, but would gradually be slimmed down for devices with ~ 2MB of RAM (that is HWCODEC devices or for that matter people who wanted a lower memory foot print SWCODEC build). The alternative I think is to keep both together indefinitely while accepting that people may not want to upgrade from what they're already running. I think this is a bad way forward because in practice if people do not upgrade, then we have left HWCODEC essentially unmaintained. People would basically be stuck with whatever bugs were built into the release or build they decide to stay with. Thoughts? Michael Received on 2011-12-15 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |