[cairo] Pixman refactoring
jeff at infidigm.net
Mon May 25 10:39:13 PDT 2009
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
> 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.
More information about the cairo