[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