Image filters: force near-zero floating point parameters to zero.

Image filters: force near-zero floating point parameters to zero.

Computation with subnormal (aka denormal) floating point values can be
an order of magnitude slower than normal values. Limiting near-zero
values to zero prevents these cases, without overly affecting the
visual result.

BUG=615851
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2198263002

[Stephen White, 2016-08-01 20:21:01]

Description was changed from

==========
Image filters: force near-zero floating point parameters to zero.

Computation with subnormal (aka denormal) floating point values can be
an order of magnitude slower than normal values. Limiting near-zero
values to zero prevents these cases, without overly affecting the
visual result.

BUG=skia:
==========

to

==========
Image filters: force near-zero floating point parameters to zero.

Computation with subnormal (aka denormal) floating point values can be
an order of magnitude slower than normal values. Limiting near-zero
values to zero prevents these cases, without overly affecting the
visual result.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2198263002
==========

[Stephen White, 2016-08-01 20:39:15]

reed@: PTAL. Thanks!

[Stephen White, 2016-08-01 20:57:27]

Description was changed from

==========
Image filters: force near-zero floating point parameters to zero.

Computation with subnormal (aka denormal) floating point values can be
an order of magnitude slower than normal values. Limiting near-zero
values to zero prevents these cases, without overly affecting the
visual result.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2198263002
==========

to

==========
Image filters: force near-zero floating point parameters to zero.

Computation with subnormal (aka denormal) floating point values can be
an order of magnitude slower than normal values. Limiting near-zero
values to zero prevents these cases, without overly affecting the
visual result.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2198263002
==========

[Stephen White, 2016-08-01 20:57:27]

senorblanco@chromium.org changed reviewers:
+ reed@google.com

[Stephen White, 2016-08-01 20:57:40]

reed@: PTAL. Thanks!

[reed1, 2016-08-01 21:12:40]

reed@google.com changed reviewers:
+ mtklein@google.com, robertphillips@google.com

[reed1, 2016-08-01 21:13:55]

is this strictly an opportunistic performance change, as I notice we're not
change *all* floats everywhere in imagefilters (or in other parts of skia)? If
so, how did you decide which code-paths to optimize and which to leave alone?

[Stephen White, 2016-08-01 21:17:08]

On 2016/08/01 21:13:55, reed1 wrote:
> is this strictly an opportunistic performance change, as I notice we're not
> change *all* floats everywhere in imagefilters (or in other parts of skia)? If
> so, how did you decide which code-paths to optimize and which to leave alone?

I audited all paths in image filters where the floats were used for computation 
directly in pixel loops. Those which were converted up-front to integer or did 
not have a per-pixel impact I ignored. It's entirely possible I missed some.

[Stephen White, 2016-08-01 21:17:59]

Description was changed from

==========
Image filters: force near-zero floating point parameters to zero.

Computation with subnormal (aka denormal) floating point values can be
an order of magnitude slower than normal values. Limiting near-zero
values to zero prevents these cases, without overly affecting the
visual result.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2198263002
==========

to

==========
Image filters: force near-zero floating point parameters to zero.

Computation with subnormal (aka denormal) floating point values can be
an order of magnitude slower than normal values. Limiting near-zero
values to zero prevents these cases, without overly affecting the
visual result.

BUG=615851
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2198263002
==========

[Stephen White, 2016-08-01 21:19:40]

The CQ bit was checked by senorblanco@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-01 21:19:46]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-01 22:02:28]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-01 22:02:29]

Dry run: This issue passed the CQ dry run.

[inferno, 2016-08-25 02:55:42]

inferno@chromium.org changed reviewers:
+ inferno@chromium.org

[inferno, 2016-08-25 02:55:42]

friendly ping ? Is this security fix ready to land ?

[Stephen White, 2016-08-25 04:32:31]

On 2016/08/25 02:55:42, inferno wrote:
> friendly ping ? Is this security fix ready to land ?

I've already landed an alternate fix for x86. The ARM version is done but
doesn't seem to work.
This is a kind of back-up plan, in case I can't get the ARM fix to work, but I'd
rather not land it,
since it's intrusive and error-prone.

Since it seems that main-frame-before-activation in CC has made the repro
near-impossible to
do on ARM, I'm tempted to just land the ARM fix and call it done, unless someone
can repro.

[reed1, 2016-08-26 17:49:44]

If we're going to land this in skia, do we have a test that can tell us if/when
we accidentally add new code that *doesn't* remember to manually filter its
values? This seems very fragile without that sort of thing.

https://codereview.chromium.org/2198263002/diff/1/include/core/SkScalar.h
File include/core/SkScalar.h (right):

https://codereview.chromium.org/2198263002/diff/1/include/core/SkScalar.h#new...
include/core/SkScalar.h:231: static inline SkScalar SkScalarNormalize(SkScalar
x)
Given this name, should it trigger only when x is denormalized?
SkScalarNearlyZero is some made up value, mostly not related to denormalized
issues.