On Sat, May 23, 2009 at 05:24:31PM +0200, Soeren Sandmann wrote: > Jeff Muizelaar <[email protected]> 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 _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
