Hello all,


We're planning on landing the code for retaining display lists in 58,
behind the pref layout.display.list.retain.


This is a rather large reworking of how we paint, and was designed to
address telemetry results [1] showing that display list building was
consuming considerable amounts of our total paint time (around 40% on
average). The new code retains the display list, and attempts to merge
in partial updates rather than rebuilding the list from scratch each
paint (as we currently do). We're tracking this in bug 1352499, which
includes a link to all the planning and telemetry details.


Miko Mynttinen has been working on gathering some performance data [2],
which is showing some really big wins, including a 77% reduction in
display list building time on YouTube when we manage to do a partial
update. These are just preliminary results, and we have a lot of
remaining plans to build off this architecture and get further wins. We
also have a few talos regressions due to the increased bookkeeping
required for this, though we're working on minimizing these as much as
possible. This is due to most Talos tests measuring first paint
performance, and this change optimizes the second (and later) paints,
which we believe to be more useful for perceived performance.


We're planning to land into mozilla-central in the next week or two, and
then enable it by default for Nightly within a week or two of that. I'll
send a follow-up email once we do land so that anyone interested can
flip the pref and give us early feedback. Our current plan is to ride
the trains for 58, possibly with a partial rollout for beta, and we'll
make a decision on that closer to the merge date.


We do have significant testing for this via reftests, though it has been
identified that we have a relative lack of testing for dynamic changes.
Jonathan Watt is working on a fuzzer addition to the reftest harness
that will generate random mutations which will increase our confidence
in correctness and stability here.



Thanks to everyone who has helped work on this, including: Miko
Mynttinen, Timothy Nikkel, Markus Stange, Ethan Lin and Jonathan Watt.



- Matt



[1]
https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2017-10-05&keys=r!dl%252Cflb!dl!flb&max_channel_version=beta%252F57&measure=CONTENT_LARGE_PAINT_PHASE_WEIGHT&min_channel_version=null&os=Windows_NT&processType=*&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2017-09-25&table=0&trim=1&use_submission_date=0
<https://telemetry.mozilla.org/new-pipeline/dist.html#%21cumulative=0&end_date=2017-10-05&keys=r%21dl%252Cflb%21dl%21flb&max_channel_version=beta%252F57&measure=CONTENT_LARGE_PAINT_PHASE_WEIGHT&min_channel_version=null&os=Windows_NT&processType=*&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2017-09-25&table=0&trim=1&use_submission_date=0>

[2]http://miko.lol/shared/mozilla/retained-dl-measurements-2017-10-05.pdf

On 10/8/17 8:22 PM, Matt Woodrow wrote:
> We're planning to land into mozilla-central in the next week or two, and
> then enable it by default for Nightly within a week or two of that.

This is awesome news.  Big thanks to everyone who worked on this!

-Boris

On Monday, October 9, 2017 at 1:22:55 PM UTC+13, Matt Woodrow wrote:

>
> We're planning on landing the code for retaining display lists in 58,
> behind the pref layout.display.list.retain.
>

This has now landed in Nightly, and looks to be working really well.

We'd really appreciate some early feedback, so feel free to set layout.display-list.retain=true and give it a try!

Please file bugs blocking 1352499 if you find any issues.

Thanks!

 - Matt

Hi Matt,

  We just re-run the Hasal against the latest nightly with
layout.display-list.retain=true,

  and you can see the detail report as below:

https://gist.github.com/ShakoHo/f9a654e327ee9dfa499584a8eeb27b7a

 Summary:

   - 60% of test cases(12/20) indicate AIL time improved on this testing
   target build
   - The test cases listed below show significant improvement ail time
   -
      - test_firefox_amazon_ail_hover_related_product_thumbnail
   -
      - test_firefox_facebook_ail_click_open_chat_tab
   -
      - test_firefox_gmail_ail_open_mail

Feel free to ask if there is any question
Regards,
Shako

--
Senior Software Engineer,
Firefox Mozilla

On Tue, Oct 31, 2017 at 6:16 PM, Kan-Ru Chen <kc...@mozilla.com> wrote:

> Looks good!
>
> Could you share this to the other mail list? Thanks!
>
> Kanru
>
>
> On Tue, Oct 31, 2017, at 05:43 PM, Shako Ho wrote:
>
> Hi Kan-Ru,
>
>   Please check the detail report below:
>
> https://gist.github.com/ShakoHo/f9a654e327ee9dfa499584a8eeb27b7a
>
>   Summary:
>
>    - 60% of test cases(12/20) indicate AIL time improved on this testing
>    target build
>    - The test cases listed below show significant improvement ail time
>    -
>       - test_firefox_amazon_ail_hover_related_product_thumbnail
>       -
>       - test_firefox_facebook_ail_click_open_chat_tab
>       -
>       - test_firefox_gmail_ail_open_mail
>
>
> --
> Senior Software Engineer,
> Firefox Mozilla
>
> On Mon, Oct 30, 2017 at 5:29 PM, Kan-Ru Chen <kc...@mozilla.com> wrote:
>
> RDL is in Nightly now. Time to test again?
>
> Kanru
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
> --
> You received this message because you are subscribed to the Google Groups
> "hasal-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to hasa...@mozilla.com.
> To post to this group, send email to hasa...@mozilla.com.
> To view this discussion on the web visit https://groups.google.com/a/mo
> zilla.com/d/msgid/hasal-dev/1509355750.2035304.1155294128.4C
> 0C7C44%40webmail.messagingengine.com.
>
>
>

How is the AIL metric defined? I looked around Hasal for a bit, but I
didn't see a clear definition.

Is it similar to RAIL[1], or something entirely different?

[1]: https://developers.google.com/web/fundamentals/performance/rail

- Ryan

Hi J. Ryan,

Yes, the concept of AIL is pretty similar to the definition of input
latency of RAIL.


RAIL StepKey MetricUser Actions
Response Input latency (from tap to paint) < 100ms. User taps a button (for
example, opening navigation

And I think the only difference is Hasal using different approach to get
the value..

Regards,
Shako

J. Ryan Stinnett <jry...@gmail.com>於 2017年10月31日 週二，下午10:34寫道：
> --

On Oct 26, 2017 12:15 AM, <mwoo...@mozilla.com> wrote:

On Monday, October 9, 2017 at 1:22:55 PM UTC+13, Matt Woodrow wrote:
> We're planning on landing the code for retaining display lists in 58,
> behind the pref layout.display.list.retain.
>

This has now landed in Nightly, and looks to be working really well.

We'd really appreciate some early feedback, so feel free to set
layout.display-list.retain=true and give it a try!

Anecdotely this pref seems to make twitter much less janky on fennec on my
Nexus 5x.

What's the plan for enabling by default?

Thanks!

Ben

On Tue, Oct 31, 2017 at 11:44 PM, Ben Kelly <bke...@mozilla.com> wrote:

> Anecdotely this pref seems to make twitter much less janky on fennec on my
> Nexus 5x.
>

Actually, at least some retained display list code is disabled in non-e10s
because of a process type check.  Its unclear what flipping the pref does
or does not do on fennec at the moment.

I filed a bug for the process checks currently being used here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1413526

Sorry for my confusion.

Ben

And now it's enabled by default for mozilla-central, and should go out in tonight's Nightly.

As above, please file bugs blocking 1352499 if you find any issues.

Thanks!

- Matt

This is really awesome. Nice work!