Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: HWCODEC

HWCODEC

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