[MPlayer-dev-eng] [PATCH] vf_eq2 + vf_eq

Hampa Hug hampa at hampa.ch
Sat Feb 1 02:43:35 CET 2003


D Richard Felker III wrote:

> Two approaches I see:
> 
> 1) Always pass brightness, contrast, gamma, and lut even to functions
>    that don't need them. There's a stupid compiler warning that will
>    complain about unused arguments, but that's lame and should be
>    disabled anyway.
> 
> 2) Only use function pointers when there are multiple implementations
>    of the same function (i.e. C and asm/vector versions), and use
>    actual conditionals for different algorithms.
> 
> IMHO approach #2 is cleaner and makes more sense to people reading the
> code, but it's your call. Of course you could sorta combine methods
> with small wrapper functions that take the vf_eq2_t pointer and then
> call the real implementation functions, but that seems sorta wasteful
> and silly.

I gave it another overhaul. I think this patch is reaching its
final state. There's now a full set of parameters (c/b/g) for
each channel. This is much more orthogonal.

Hue adjustment had to go. It just doesn't fit in. Besides,
I don't see much use for it anyway. I suppose that if
somebody needed it then somebody could hack it in again. But
that somebody would not be me ;-)

I may have screwd up the independant gamma part. I don't
fully understand that part. Results look OK, though.


> > > Also, you should name the functions by what they do. E.g.
> > > adjust_y_MMX -> affine_1d_MMX or something, rather than just
> > > "adjust_{plane}".
> > 
> > ACK.
>
> Hm? ACK = acknowledge, or ACK = disgusting? :)

ACK as in "I agree (but AFAICS it was you who named the function
'process_MMX' in the first place)" ;-)

Hampa
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: vf_eq2-2003-02-01.diff
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20030201/dfde206d/attachment.txt>


More information about the MPlayer-dev-eng mailing list