[FFmpeg-devel] [PATCH 3/4] Implement and use shareable ff_transpose function.

[Michael Niedermayer]

On Tue, Nov 23, 2010 at 09:27:43PM +0100, Stefano Sabatini wrote:
> On date Thursday 2010-11-04 00:54:58 +0100, Michael Niedermayer encoded:
> > On Wed, Nov 03, 2010 at 10:43:56PM +0100, Stefano Sabatini wrote:
> > > On date Thursday 2010-10-28 16:38:35 -0700, Stefano Sabatini encoded:
> > > > On date Thursday 2010-10-21 01:37:38 +0200, Michael Niedermayer encoded:
> > > > > On Mon, Oct 18, 2010 at 02:09:54PM +0200, Stefano Sabatini wrote:
> > > > [...]
> > > > > > So what's the best course of action to follow now?
> > > > > > 
> > > > > > We have three filters (one of which committed: hflip, tranpose,
> > > > > > rotate90) which may share common code during the init stage. Currently
> > > > > > they are in separate files, so which is the best way to make them
> > > > > > share the optimization code?
> > > > > 
> > > > > I dont know but id say hflip and transpose can be optimized and rotate90 should
> > > > > use them somehow
> > > > 
> > > > Provided that right now I don't care about the optims but I want to
> > > > commit the rotate90 filter, I'd stick with my proposed solution as you
> > > > didn't suggest a better one, optims gurus can take what's required
> > > > later if they'll proceed with optimizations.
> > > 
> > > Ping? OK to apply this and leave it to asm-savvy people? 
> > 
> > id say if you dont care about factorizing the code in a way thats easy to use
> > for optims then leave it duplicated
> 
> I'm still waiting for a useful description of how to do that.

just drop this patch.
And when you need to transpose elsewhere write the 20 lines of c code there

if someone wants to optimize this he can factor or not factor it as it works
out best. But factorizing 2x20 lines now into 140 lines that cannot be
optimized as they are afterwards really is not a good idea.


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I hate to see young programmers poisoned by the kind of thinking
Ulrich Drepper puts forward since it is simply too narrow -- Roman Shaposhnik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101125/cff50609/attachment.pgp>