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. 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
_______________________________________________
xorg-devel mailing list
[email protected]
http://lists.x.org/mailman/listinfo/xorg-devel
