[cairo] Pixman refactoring

[Soeren Sandmann]

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. 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.


Thanks for the comments,
Soren