Remove sk_bzero usage from SkMatrix44 for improved performance.

Remove sk_bzero usage from SkMatrix44 for improved performance.

sk_bzero is not efficient for initializing small chunks of memory. Instead,
directly initializing matrix values when needed results in substantial
performance improvements.

BUG=skia:1558

[shawnsingh, 2013-08-24 03:41:31]

PTAL.  benchmarks are here https://codereview.chromium.org/22872015/ that would
land first.

thanks in advance =)

[shawnsingh, 2013-08-24 04:51:22]

+epenner because of the precision tradeoff for theoretically axis-aligned
scale/translations.

The second patch for scale/translate inversion is even 25% faster than the first
patch =)  Scale translate matrix inversion benchmark went from 2.95 --> 1.95
without sk_bzero --> 1.45 with new implementation.

However - the new implementation avoids 2 division operations by replacing them
with more addition/subtractions.  I wonder if precision may be slighty reduced
as a result of the additional arithmetic?  If this is a deal-breaker, we can
revert back to the approach in the first patch.

[reed1, 2013-08-26 12:25:09]

On 2013/08/24 04:51:22, shawnsingh wrote:
> +epenner because of the precision tradeoff for theoretically axis-aligned
> scale/translations.
> 
> The second patch for scale/translate inversion is even 25% faster than the
first
> patch =)  Scale translate matrix inversion benchmark went from 2.95 --> 1.95
> without sk_bzero --> 1.45 with new implementation.
> 
> However - the new implementation avoids 2 division operations by replacing
them
> with more addition/subtractions.  I wonder if precision may be slighty reduced
> as a result of the additional arithmetic?  If this is a deal-breaker, we can
> revert back to the approach in the first patch.

Since there is a precision question, perhaps that proposed CL should be
separated out

[shawnsingh, 2013-08-27 10:39:25]

On 2013/08/26 12:25:09, reed1 wrote:
> On 2013/08/24 04:51:22, shawnsingh wrote:
> > +epenner because of the precision tradeoff for theoretically axis-aligned
> > scale/translations.
> > 
> > The second patch for scale/translate inversion is even 25% faster than the
> first
> > patch =)  Scale translate matrix inversion benchmark went from 2.95 --> 1.95
> > without sk_bzero --> 1.45 with new implementation.
> > 
> > However - the new implementation avoids 2 division operations by replacing
> them
> > with more addition/subtractions.  I wonder if precision may be slighty
reduced
> > as a result of the additional arithmetic?  If this is a deal-breaker, we can
> > revert back to the approach in the first patch.
> 
> Since there is a precision question, perhaps that proposed CL should be
> separated out

I spoke with epenner@ just a few hours ago, and precision should not be an issue
with this patch.  I'm happy to land either patch, but I think we can move
forward with patch 2 which is 25% faster, if that's OK with you =)

[shawnsingh, 2013-08-27 10:42:54]

By the way, I did not forget your suggestion to pull functions out into helper
functions.  I can do that in a separate patch, so that we can clearly check that
the helper functions do not regress perf.

[reed1, 2013-08-27 16:07:58]

lgtm

[shawnsingh, 2013-08-29 07:37:21]

landed in https://code.google.com/p/skia/source/detail?r=10988