[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