Allow compiler to optimize applying quadratic UV matrix to verts

[bsalomon, 2012-03-15 13:03:34]

This gives a small improvement to the cpu performance of the convex path
renderer. It avoids computing an SkMatrix typemask (which will always be
rot/trans) and allows the compiler to unroll a loops which reduces the time
spent applying the matrix from ~2% to ~.5% in a real world profile.

[reed1, 2012-03-15 13:28:18]

Looks fine. A little too bad we have to pass void* instead of some templated
type (or float*).

I presume count is always small (4 or 6). Since we plan to add SSE2 (etc.)
optimizations for matrix procs, I just don't want to work-around that for cases
which might benefit in the future.

[bsalomon, 2012-03-15 13:41:32]

On 2012/03/15 13:28:18, reed1 wrote:
> Looks fine. A little too bad we have to pass void* instead of some templated
> type (or float*).

Yes, but the vertices are really little structs made up of points, float[4], and
uint32_t and can vary depending on the caller. I thought void* better
communicated that were dealing with packed vertices not arrays of some type
defined in C.

> 
> I presume count is always small (4 or 6). Since we plan to add SSE2 (etc.)
> optimizations for matrix procs, I just don't want to work-around that for
cases
> which might benefit in the future.

Yes, currently 5 or 6. BTW I did spend a good deal of time on a COUNT=6 SSE
implementation. I didn't get much of a win over the templated version. Most of
the time is spent waiting for loads which the compiler can do a good job of
hiding by unrolling and using the usual FPU instructions. It didn't seem worth
the additional code complexity for the trivial additional performance.

[bsalomon, 2012-03-15 14:41:58]

Closed with r3398