[MPlayer-dev-eng] Slideshow
Herman Tamas
hermantom at dunasoft.com
Fri Dec 13 13:54:40 CET 2002
this should go 2 private but the dest address is unknown, sorry.
On Fri, 13 Dec 2002 06:31:36 -0500
"Daniel A. Nagy" <nagydani at mast.queensu.ca> wrote:
> On Thu, Dec 12, 2002 at 08:33:06PM -0500, D Richard Felker III wrote:
> > Do you have any idea what you're talking about? I certainly don't. As
sorry, i was terribly tired that night. also made a lot of syntactic
mistakes. so iwasnt clear, i should agree on that. im gonna b more clear
next time.
but conscisely again:
- dont use buggy libs & make workarounds outside if its possible
2 fix the bug inside. it requires continous manual sync 2 the lib
later what is a tedious work what involves a lot of text scrolling
& lot of typing. but the result is a pretty high quality sw.
(see ffmpeg&mplayer. they r a nice example of this methodology)
- C is 2 terse & not highlevel enough 2 express the top/surface/most
outside mechanisms of a more complex program, like mplayer, in
terse/conscise/clean & easily understandable fashion. adding such
an extra language layer is obviously lowers performance unless
u use the proper language... BUT! it can also boost productivity!
and eases further development & MAINTENENCE... wheather such a
higher level lang been incorporated or not in2 mplayer, programmers
should write mplayer such a way so putting any HLL over it should
b an obvious task.. the only thing is required 4 this is a very
high level of modularization, even factorization, ithink...
(also Arpi whats a more modular design...)
the above things sound obvious of course but still not taken
care of. so hear my meassage 2 the developers: do more design
b4 doing the actual coding! its gonna make everybodys life
easier, even yours.
a practical adivce: do more fine architectural descriptions jsut
like Arpi did eg, in DOCS/tech/libmpcodecs.txt . draw such graphs
more!
More information about the MPlayer-dev-eng
mailing list