return if we're invertible for the fast scale+trans case when we have no inverse

return if we're invertible for the fast scale+trans case when we have no inverse
matrix to return.
Committed: https://code.google.com/p/skia/source/detail?r=7464

[edisonn, 2013-01-30 15:43:19]

LGTM

[reed1, 2013-01-30 17:05:33]

Very minor changes are expected, as we perform different sets of FP operations
in the new code path. However, I think the new results are more accurate
(performs fewer adds and muls, so less chance to accumulate error), and they are
definitely faster.

When this originally landed, we did some rebaselining in our raster images, for
very minor differences which were determined to be insignificant. Are you seeing
large changes that might be indicative of a bug in the code?

[edisonn, 2013-01-30 17:07:34]

Thanks. No, the changes are very small.



On Wed, Jan 30, 2013 at 12:05 PM, <reed@google.com> wrote:

> Very minor changes are expected, as we perform different sets of FP
> operations in the new code path. However, I think the new results are
> more accurate (performs fewer adds and muls, so less chance to
> accumulate error), and they are definitely faster.
>
> When this originally landed, we did some rebaselining in our raster
> images, for very minor differences which were determined to be
> insignificant. Are you seeing large changes that might be indicative of
> a bug in the code?
>
>
https://codereview.appspot.**com/7231063/<https://codereview.appspot.com/7231...
>

[edisonn, 2013-01-30 17:08:11]

more exact:

I rendered skps to pdf, and the change affects only 1 pdf (tabl_gmail) in a
minor way, with no visual changes

/ProcSet [/PDF /Text /ImageB /ImageC /ImageI]
>>
/Matrix [8.6667 0 0 -1 -0.0001 907]                 #define
SK_IGNORE_FAST_SCALEMATRIX_INVERT
/Matrix [8.6667 0 0 -1 0.0001 907]                  don't #define
SK_IGNORE_FAST_SCALEMATRIX_INVERT


On Wed, Jan 30, 2013 at 12:07 PM, Edison Nica <edisonn@google.com> wrote:

> Thanks. No, the changes are very small.
>
>
>
> On Wed, Jan 30, 2013 at 12:05 PM, <reed@google.com> wrote:
>
>> Very minor changes are expected, as we perform different sets of FP
>> operations in the new code path. However, I think the new results are
>> more accurate (performs fewer adds and muls, so less chance to
>> accumulate error), and they are definitely faster.
>>
>> When this originally landed, we did some rebaselining in our raster
>> images, for very minor differences which were determined to be
>> insignificant. Are you seeing large changes that might be indicative of
>> a bug in the code?
>>
>>
https://codereview.appspot.**com/7231063/<https://codereview.appspot.com/7231...
>>
>
>