[cairo] Pixman refactoring

Soeren Sandmann sandmann at daimi.au.dk
Sat May 23 08:24:31 PDT 2009

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,

More information about the cairo mailing list