[MPlayer-dev-eng] Re: [PATCH] Development (Was: Clean up

[Arpi]

Hi,

> > > problem with reckless declaration of new scopes at random places in the
> > > code simply because the programmer wanted another local variable right
> > > there. Now that's just sloppy.
> > 
> > I still can't see the problem with this
> 
> 	While a piece of code may be technically valid, and may even
> compile without warnings, that doesn't make it understandable. IOW, just
> because you *could* doesn't mean you *should*. E.g., just because we
> *could* actively maintain a Windows port of MPlayer doesn't mean we
> *should*...:)

Maybe I'm silly, but its' fully clean and readable for me. I would implement
it at the same way... so I will probably never understand what is the
problem with it, until someone shows me the same code 'reorganized'.
Anyway I'm sure in that reorganized version will be less cleaner for me and
maybe even slower (anyway speed doesn't matters there, it's cmdline parser).

> 	Bottom line: Properly written and organized code lends itself to
> readability, understanding, functionality, and maintainability, all
> without impacting program performance.

I agree, but it REQUIRES few years of designing and planning code before
writting down the first line of code. I did it in a company, developing
commercial stuff in Java. They desigend the stuf for 1.5 years long, then
started to implement it, teh whole work splitted to small parts assigned to
independent developers. After a year of work, they started to realize design
issues, redesign parts and restart from scratch. I'm sure finally it will be
nice, organized, fast etc code, but it will took years and they will paid
millions for many fulltime programmers...

Do you remember libvo2 ? It was teh same story... designing took too long
and we still can't see if someone will ever start implementing it.

MPlayer has grown up from the scratch, by adding small clean (in my
dictionary) patches and sometimes reorganizing parts while keep its style
but make its interface better and faster. And we'll continue this way.
And this approach will ensure that CVS is always stable, and working.

> > > subsystem needs help (almost as much as the decoding subsystem needs hel
> p,
> > > but that's another thread...:)
> > i'm working on that right now
> 
> 	Really? So was I. We should really compare notes sometime...:)

Send patch...
I'm still on designing, so didn't wrote a single code down for this.
Did you read/remember my mail, with subject like libmpcodecs vs. direct
rendering or so. It was a draft about what and how to do, now i'm writting
down interface details, constants etc. I wanted to start implementing today
but was busy so it will be delayed to tomorrow.

At first step it will mean creating .h files, and moving video decoders to
vd_drivername.c files using the new api in compatible way. If it's done,
i'll commit, then start to change codecs to use new features of the api,
like direct rendering, common buffer handling, automatic common colorspace
conversion and filtering, crop+extend+scale etc...


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu