Remove DWrite locks

Remove DWrite locks

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

[tzik, 2016-05-31 05:52:11]

Description was changed from

==========
Remove DWrite locks

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

to

==========
Remove DWrite locks

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

[tzik, 2016-06-27 08:08:32]

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

[commit-bot: I haz the power, 2016-06-27 08:08:42]

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-06-27 08:25:32]

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

[commit-bot: I haz the power, 2016-06-27 08:25:32]

Dry run: This issue passed the CQ dry run.

[tzik, 2016-06-28 03:19:50]

Description was changed from

==========
Remove DWrite locks

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

to

==========
Remove DWrite locks

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

[tzik, 2016-06-28 03:19:50]

tzik@chromium.org changed reviewers:
+ kouhei@chromium.org

[kouhei (in TOK), 2016-06-28 04:39:30]

Given that this is a controversial change, we want to be sure that performance
benefit is worth it.
Would you collect performance numbers on windows machine?
e.g) TTFMP was 1000ms, raster took 100ms, applying CL made raster 50ms -> X%
impact in user perceived page load latency

[tzik, 2016-06-28 12:28:35]

On 2016/06/28 04:39:30, kouhei wrote:
> Given that this is a controversial change, we want to be sure that performance
> benefit is worth it.
> Would you collect performance numbers on windows machine?
> e.g) TTFMP was 1000ms, raster took 100ms, applying CL made raster 50ms -> X%
> impact in user perceived page load latency

Sure. On a text-heavy English site [1], the improvement was 9ms (1.5%, relative
to TTFCP). And on a text-heavy Japanese site [2], it was 70ms (9%, relative to
TTFCP).
On [1], TTFCP was 593ms. The rasterization after TTFCP took 18ms without this
CL, and took 9.3ms with this CL.
On [2], TTFCP was 759ms. The rasterization took 78.3ms without this CL, and took
8.0ms with this CL.

[tzik, 2016-06-29 05:44:34]

On 2016/06/28 12:28:35, tzik wrote:
> On 2016/06/28 04:39:30, kouhei wrote:
> > Given that this is a controversial change, we want to be sure that
performance
> > benefit is worth it.
> > Would you collect performance numbers on windows machine?
> > e.g) TTFMP was 1000ms, raster took 100ms, applying CL made raster 50ms -> X%
> > impact in user perceived page load latency
> 
> Sure. On a text-heavy English site [1], the improvement was 9ms (1.5%,
relative
> to TTFCP). And on a text-heavy Japanese site [2], it was 70ms (9%, relative to
> TTFCP).
> On [1], TTFCP was 593ms. The rasterization after TTFCP took 18ms without this
> CL, and took 9.3ms with this CL.
> On [2], TTFCP was 759ms. The rasterization took 78.3ms without this CL, and
took
> 8.0ms with this CL.

Oops, I forgot to add the URLs.
[1]: https://en-us.facebook.com/terms
[2]: https://ja-jp.facebook.com/terms