[cairo] Pixman refactoring

[Jeff Muizelaar]

On Sat, May 23, 2009 at 05:24:31PM +0200, Soeren Sandmann wrote:
> Jeff Muizelaar <jeff at infidigm.net> writes:
> 
> > > I'm wondering about the benefit of the indirection to the delegate
> > > implementation. I can't think of any situations where an implementation
> > > wouldn't know it's delegate statically. Any thoughts?
> 
> You're right that the delegate would be statically known in almost all
> cases, though I could imagine things like ARM CPUs with NEON but not
> v6 SIMD, or incompatible AMD/Intel instruction sets, where the
> fallback would have to be determined at runtime.
> 
> The main advantage that I see of turning those delegate calls into
> static calls is that it may make it easier to see what code actually
> ends up running. 

Yeah, clarity was my biggest concern. I don't know how much a difference
it makes.

> If we get rid of the _pixman_implemntation_foo()
> wrappers, then I don't think there is any real performance advantage
> since the remaining indirect calls would be 100% predictable.
> 
> There would be a couple of disadvantages though:
> 
>     - All of the calls from all of the implementations would have to
>       be non-static functions and declared in header files
> 
>     - If an implementation at some point gets a different delegate,
>       there is more code that needs to be changed. 
> 
> > Another question:
> > 
> > In _pixman_implementation_create () you fill out the function pointers
> > with ones that just delegate. Why not just fill in the functions from
> > the delegate? Is the delegate of an implementation expected to change
> > after it's been created?
> 
> Filling in the delegate functions directly wouldn't work because the
> delegate functions would be called with a pointer to the original
> implementation rather than the delegate implementation, so if they
> tried to delegate further, they'd just end up calling themselves.

Ah of course, that makes sense.

-Jeff