[MPlayer-dev-eng] another RGB ordering fix for altivec

[Ivan Kalvachev]

2006/3/18, Alan Curry <pacman at theworld.com>:
> Ivan Kalvachev writes the following:
> >
> >2006/3/16, Alan Curry <pacman at theworld.com>:
> >> Ivan Kalvachev writes the following:
> >> >
> >> >Could there be argb64 ?? (e.g. film gimp / cine paint)
> >>
> >> At an unspecified future time, it could appear. Then we'd either
> >> s/IMGFMT_ARGB/IMGFMT_ARGB32/ throughout mplayer or decide to keep it as it
> >> is, with the 32 implied. Either way, why should that stop us from using
> >> consistent names for 32-bit formats now?
> >
> >MPlayer policy is to highly discourage non-functional/cosmetic changes.
>
> And what a wonderful dogma that is! It's probably why mplayer is one of the
> few packages for which a recursive, indiscriminate `indent --gnu' would be an
> improvement.

(discouraged < forbidden)

Indeed. I am in favour of automatic indent when committing code.
Unfortunately we cannot agree on what indent options should be used.
Some developers find indent changes disturbing when reviewing patches...
(but if we have automatic indent_on_commit then we could request
patches to be made ignoring white spaces... Well maybe when we move to
svn)
Some developers want their tabulating to be preserved.

> >So it is better to do it in a way you will be sure that you won't have
> >to do such things.
>
> This did fix a bug (play something -vf format=rgb32,scale with altivec and
> the colors were wrong), and the bug was directly related to the confusion
> over what these argb32/bgra32 functions actually do. Something had to be
> changed.

Fixing bugs is perfectly fine. You asked for advice and I recommend
you to use the style that have less chanse to be changed.

You can commit your code at any time.