[cairo] Pixman refactoring, ARM and Altivec implementations needed

[Jonathan Morton]

> > I plan to send these blitters upstream very soon, but this kind of
> > lossage is *exactly* what I was hoping to avoid.  :-(
> 
> I understand and share your pain. But I guess upstream is just happy that
> someone who can fix those issues is around, and takes it as a chance for
> introducing some long planned changes :-)
> 
> I personally would prefer to get all the high level optimizations integrated
> into pixman first. Those are quite problematic to keep in sync with upstream
> when upstream code is undergoing refactoring. On the other hand, assembly
> optimized blitters are quite isolated and it is much harder to break them on
> refactoring, so those are relatively safe.

I'm hoping that the refactor will itself introduce some high-level
optimisations, such as a shortening of the path to the fast blitters.

So far, it's got worse rather than better, especially as the number and
size of the parameters being passed around has just increased
significantly.  (There are too many of them to keep in registers even on
a RISC platform, so they occupy space on the stack, and have to be
copied for each call.)

And this refactor step *did* break the blitters - or rather their
interface.  I'm not complaining too loudly about that per se, since the
interface needed to be updated (and I can see it happening again), just
that the existing blitters were not all updated to suit.

This latest refactor has introduced some large performance regressions
at my end.  Some of them can be explained by the new fastpath logic not
being properly integrated for ARM platforms yet.  For others the cause
is less clear.

But because the integration was not completed for all platforms at the
same time, I can't currently tell whether a particular performance
regression is due to the refactor or due to shortcomings in the
integration.  That severely limits my ability to offer suggestions about
the refactoring itself, and my time is wasted by debugging and
implementing semi-generic code to try and get things working again.

> I'm also a bit worried about the stability of code. It would be not very good
> if a lot of new bugs get introduced during this refactoring process.

Obviously.  But that's also a good argument for all of the
architectures' implementations to have their existing features
integrated into the new system by the refactorer.  "Does not compile" is
a valid form of bug in my book.

That is how the Linux kernel does things, incidentally - internal API
changes are allowed, as long as the person changing the API also fixes
all in-tree stuff that gets broken by it.

This does mean that Soeren needs to get some cross-compilers installed
and learn how to use those, but on this particular project, I think
that's necessary.

-- 
------
From: Jonathan Morton
      jonathan.morton at movial.com