[cairo] Comments on NEON code

[Jonathan Morton]

> > // Use overlapping 8-pixel method
> 
> What is the "overlapping 8-pixel method"?

This is one of Ian's special tricks - for blitters which don't use the
destination as an input, and are at least 8 pixels wide, he makes all of
the accesses 8 pixels wide by pushing the rightmost access inwards to be
flush with the right margin.  It thus overlaps the previous iteration if
the width was not a multiple of 8.

> * Wrong multiplication
> 
> The multiplications in several of the 0565-destination compositing
> routines is done by shifting by 8. This is not correct; the correction
> computation is a division by 255, which can be done reasonably quickly
> with the old multiply-with-reciprocal trick:
> 
>      t = x + 0x80;
>      x = (t + ((t + 0x80) >> 8)) >> 8

> * Double premultiplication
> 
> Pixels that pixman deals with
> are generally premultiplied, so the Over operation looks like this:
> 
>     s + (1 - a_s) * d
> 
> There are a couple of instances of this.

We do plan to look into the scaling_test checksum failures, just as soon
as we can get a *passing* test on a reference platform.  The issues you
mention are potential causes, but we had run our own tests to
sanity-check our approach.

Hindering progress on this is the fact that scaling_test tends to use
the system-installed libpixman rather than the one just built, and on
our reference platform that's the stable (but differently-behaving)
0.14.0.  The complex shell script in the test directory Does Not Help -
replacing it with one that simply sets LD_PRELOAD would be better for us
(and most Linux developers).

Additionally, it has proved difficult to get independent CRCs out of the
test to provide a list of failing tests, as opposed to just finding the
first failing test.  Having a list allows identifying common factors in
a set of failing tests, which makes finding the cause much easier.  (We
hacked this using a slow shell-scripting technique, which identified the
use of the wrong library version... after several days' effort and CPU
time.)

Of course there are ways to work around this, but I presently have other
quite urgent things to do, so I'll have to get back to this later.

> * Minor things:

Do feel free to clean up comments.  Mine were written to cater for some
particular code reviewers, so a wider audience might not find some of
them useful.

I think the "unpack" functions may be left over from some of Ian's code
that I replaced.

I have no objection to the naming conventions being cleaned up.

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