[MPlayer-dev-eng] Re: [PATCH] Development (Was: Clean up
Daniel Egger
degger at fhm.edu
Tue Feb 26 13:28:29 CET 2002
Am Die, 2002-02-26 um 04.35 schrieb Michael Niedermayer:
> nothing from gprof can surprise me anymore ... i saw it output 0% for a
> function and on the next run it said 30% ...
> dont understnd me wrong, gprof is a very usefull tool but i wouldnt use it
> for benchmarking, thats what "mplayer -benchmark" is for
I don't care about a simple benchmark alone because it cannot show where
the hotspots are. Granted, gprof can be used incorrectly and can be a
big factor for making wrong decisions but this is the part where
experience kicks in (should, at least :)).
> > Depends on the platform, the compiler, the cpu and the day of the month.
> hmm, seems ur hardware is buggy if gcc outputs different binaries depending
> upon the day of the month
No, I always use the latest CVS version. :)
> btw, when i was implementing the swscaler i looked at the source code from
> other scalers and allso on that from gimp, and imho gimps code was the most
> unreadable code i found, i mean the code from other projects like virtualdub
> which included some assembly optimized code was much more readable, allthough
> this doesnt mean that the code is unreadable to everyone ... what iam trying
> to say is that readability and style depend upon the person and i doubt that
> the gimp developers would accept it if i "fixed" it ...
The GIMP development has a fixed codingstyle and while it is not my
preferred one it tends to be quite readable. GIMP has had a different
problem though: It started as a project as messy as mplayer and is
being refactored nowadays; if you have any patch to the unstable version
of the GIMP (being cosmetic or functional) feel free to toss it over.
--
Servus,
Daniel
More information about the MPlayer-dev-eng
mailing list