Fix png encoding performance regressions - downstream diff

Fix for png encoding performance regressions - downstream diff

The original fix was:

> Fix performance regression in png encoding caused by libpng update
>
> libpng calculates "filter heuristics" to choose which png
> filter to apply.  Chrome need not calculate these "filter
> heuristics" because we always choose to use the SUB filter,
> for speed.
>
> libpng 1.6 refactors the SUB filter to share code, also
> forcing us to calculate the filter heuristics, even though
> we don't need to.  This caused a performance regression.
>
> This CL cherry picks a fix from upstream that:
> (1) Passes PNG_SIZE_MAX to the filter code.  This allows
> the compiler to optimize out the heuristic calculation
> code, fixing the performance regression.
> (2) Fixes overflow handling in the calculation of filter
> heuristics.  This won't affect Chrome.
>
> Review-Url: https://codereview.chromium.org/2062423002

This fix was effective everywhere we use clang, but did
not work on Android (GCC) or Windows (MSVS) because the
compiler was not applying the appropriate optimizations.

This CL contains a more portable fix.  This was briefly
landed by libpng, but backed out.  They fear it increases
code size and that the compiler can be forced to make
the same optimization.

FWIW, we have demonstrated that we can force the compiler
to make the same optimization.
https://codereview.chromium.org/2119813003/

But we feel that changing the compiler options is fragile
and it is better to just carry a diff.

BUG=619850
BUG=599917
Committed: https://crrev.com/67058eff9c2a51e589388d7d494b1490530a1ec5
Cr-Commit-Position: refs/heads/master@{#404379}

[msarett, 2016-07-07 20:11:26]

Description was changed from

==========
Fix png encoding performance regressions

BUG=
==========

to

==========
Fix for png encoding performance regressions - downstream diff

The original fix was:

> Fix performance regression in png encoding caused by libpng update
>
> libpng calculates "filter heuristics" to choose which png
> filter to apply.  Chrome need not calculate these "filter
> heuristics" because we always choose to use the SUB filter,
> for speed.
>
> libpng 1.6 refactors the SUB filter to share code, also
> forcing us to calculate the filter heuristics, even though
> we don't need to.  This caused a performance regression.
>
> This CL cherry picks a fix from upstream that:
> (1) Passes PNG_SIZE_MAX to the filter code.  This allows
> the compiler to optimize out the heuristic calculation
> code, fixing the performance regression.
> (2) Fixes overflow handling in the calculation of filter
> heuristics.  This won't affect Chrome.
>
> Review-Url: https://codereview.chromium.org/2062423002

This fix was effective everywhere we use clang, but did
not work on Android (GCC) or Windows (MSVS) because the
compiler was not applying the appropriate optimizations.

This CL contains a more portable fix.  This was briefly
landed by libpng, but backed out.  They fear it increases
code size and that the compiler can be forced to make
the same optimization.

FWIW, we have demonstrated that we can force the compiler
to make the same optimization.
https://codereview.chromium.org/2119813003/

But we feel that changing the compiler options is fragile
and it is better to just carry a diff.

BUG=619850
BUG=599917
==========

[msarett, 2016-07-07 20:14:09]

msarett@google.com changed reviewers:
+ thakis@chromium.org

[msarett, 2016-07-07 20:14:09]

Not getting anywhere with libpng...  Let's go ahead and carry a diff :(.

[Nico, 2016-07-07 20:16:22]

lgtm, thanks

[Nico, 2016-07-07 20:17:39]

(if you think it helps any, i'm happy to comment upstream somewhere as well. not
sure it'll do more than you doing the same thing, though -- but maybe they're
more willing to listen to someone who works on a compiler, not sure)

[msarett, 2016-07-07 20:26:06]

The CQ bit was checked by msarett@google.com to run a CQ dry run

[commit-bot: I haz the power, 2016-07-07 20:26:41]

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-07-07 22:28:35]

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

[commit-bot: I haz the power, 2016-07-07 22:28:36]

Dry run: Try jobs failed on following builders:
  mac_chromium_gyp_rel on master.tryserver.chromium.mac (JOB_TIMED_OUT, no build
URL)

[msarett, 2016-07-07 23:53:56]

The CQ bit was checked by msarett@google.com to run a CQ dry run

[commit-bot: I haz the power, 2016-07-07 23:54:26]

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-07-08 00:28:36]

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

[commit-bot: I haz the power, 2016-07-08 00:28:36]

Dry run: This issue passed the CQ dry run.

[msarett, 2016-07-08 12:20:50]

The CQ bit was checked by msarett@google.com

[commit-bot: I haz the power, 2016-07-08 12:21:08]

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-07-08 14:29:26]

Description was changed from

==========
Fix for png encoding performance regressions - downstream diff

The original fix was:

> Fix performance regression in png encoding caused by libpng update
>
> libpng calculates "filter heuristics" to choose which png
> filter to apply.  Chrome need not calculate these "filter
> heuristics" because we always choose to use the SUB filter,
> for speed.
>
> libpng 1.6 refactors the SUB filter to share code, also
> forcing us to calculate the filter heuristics, even though
> we don't need to.  This caused a performance regression.
>
> This CL cherry picks a fix from upstream that:
> (1) Passes PNG_SIZE_MAX to the filter code.  This allows
> the compiler to optimize out the heuristic calculation
> code, fixing the performance regression.
> (2) Fixes overflow handling in the calculation of filter
> heuristics.  This won't affect Chrome.
>
> Review-Url: https://codereview.chromium.org/2062423002

This fix was effective everywhere we use clang, but did
not work on Android (GCC) or Windows (MSVS) because the
compiler was not applying the appropriate optimizations.

This CL contains a more portable fix.  This was briefly
landed by libpng, but backed out.  They fear it increases
code size and that the compiler can be forced to make
the same optimization.

FWIW, we have demonstrated that we can force the compiler
to make the same optimization.
https://codereview.chromium.org/2119813003/

But we feel that changing the compiler options is fragile
and it is better to just carry a diff.

BUG=619850
BUG=599917
==========

to

==========
Fix for png encoding performance regressions - downstream diff

The original fix was:

> Fix performance regression in png encoding caused by libpng update
>
> libpng calculates "filter heuristics" to choose which png
> filter to apply.  Chrome need not calculate these "filter
> heuristics" because we always choose to use the SUB filter,
> for speed.
>
> libpng 1.6 refactors the SUB filter to share code, also
> forcing us to calculate the filter heuristics, even though
> we don't need to.  This caused a performance regression.
>
> This CL cherry picks a fix from upstream that:
> (1) Passes PNG_SIZE_MAX to the filter code.  This allows
> the compiler to optimize out the heuristic calculation
> code, fixing the performance regression.
> (2) Fixes overflow handling in the calculation of filter
> heuristics.  This won't affect Chrome.
>
> Review-Url: https://codereview.chromium.org/2062423002

This fix was effective everywhere we use clang, but did
not work on Android (GCC) or Windows (MSVS) because the
compiler was not applying the appropriate optimizations.

This CL contains a more portable fix.  This was briefly
landed by libpng, but backed out.  They fear it increases
code size and that the compiler can be forced to make
the same optimization.

FWIW, we have demonstrated that we can force the compiler
to make the same optimization.
https://codereview.chromium.org/2119813003/

But we feel that changing the compiler options is fragile
and it is better to just carry a diff.

BUG=619850
BUG=599917
==========

[commit-bot: I haz the power, 2016-07-08 14:29:27]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-07-08 14:32:41]

Description was changed from

==========
Fix for png encoding performance regressions - downstream diff

The original fix was:

> Fix performance regression in png encoding caused by libpng update
>
> libpng calculates "filter heuristics" to choose which png
> filter to apply.  Chrome need not calculate these "filter
> heuristics" because we always choose to use the SUB filter,
> for speed.
>
> libpng 1.6 refactors the SUB filter to share code, also
> forcing us to calculate the filter heuristics, even though
> we don't need to.  This caused a performance regression.
>
> This CL cherry picks a fix from upstream that:
> (1) Passes PNG_SIZE_MAX to the filter code.  This allows
> the compiler to optimize out the heuristic calculation
> code, fixing the performance regression.
> (2) Fixes overflow handling in the calculation of filter
> heuristics.  This won't affect Chrome.
>
> Review-Url: https://codereview.chromium.org/2062423002

This fix was effective everywhere we use clang, but did
not work on Android (GCC) or Windows (MSVS) because the
compiler was not applying the appropriate optimizations.

This CL contains a more portable fix.  This was briefly
landed by libpng, but backed out.  They fear it increases
code size and that the compiler can be forced to make
the same optimization.

FWIW, we have demonstrated that we can force the compiler
to make the same optimization.
https://codereview.chromium.org/2119813003/

But we feel that changing the compiler options is fragile
and it is better to just carry a diff.

BUG=619850
BUG=599917
==========

to

==========
Fix for png encoding performance regressions - downstream diff

The original fix was:

> Fix performance regression in png encoding caused by libpng update
>
> libpng calculates "filter heuristics" to choose which png
> filter to apply.  Chrome need not calculate these "filter
> heuristics" because we always choose to use the SUB filter,
> for speed.
>
> libpng 1.6 refactors the SUB filter to share code, also
> forcing us to calculate the filter heuristics, even though
> we don't need to.  This caused a performance regression.
>
> This CL cherry picks a fix from upstream that:
> (1) Passes PNG_SIZE_MAX to the filter code.  This allows
> the compiler to optimize out the heuristic calculation
> code, fixing the performance regression.
> (2) Fixes overflow handling in the calculation of filter
> heuristics.  This won't affect Chrome.
>
> Review-Url: https://codereview.chromium.org/2062423002

This fix was effective everywhere we use clang, but did
not work on Android (GCC) or Windows (MSVS) because the
compiler was not applying the appropriate optimizations.

This CL contains a more portable fix.  This was briefly
landed by libpng, but backed out.  They fear it increases
code size and that the compiler can be forced to make
the same optimization.

FWIW, we have demonstrated that we can force the compiler
to make the same optimization.
https://codereview.chromium.org/2119813003/

But we feel that changing the compiler options is fragile
and it is better to just carry a diff.

BUG=619850
BUG=599917

Committed: https://crrev.com/67058eff9c2a51e589388d7d494b1490530a1ec5
Cr-Commit-Position: refs/heads/master@{#404379}
==========

[commit-bot: I haz the power, 2016-07-08 14:32:42]

Patchset 1 (id:??) landed as
https://crrev.com/67058eff9c2a51e589388d7d494b1490530a1ec5
Cr-Commit-Position: refs/heads/master@{#404379}