<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Yes, I'll update that document today.</div></blockquote><div><br></div><div>I have updated the document to refer to the new BrowserUtils.jsm helpers.</div><div class="gmail_extra"><br><div class="gmail_quote">On 2 August 2017 at 15:22, Mike Conley <span dir="ltr"><<a href="mailto:mconley@mozilla.com" target="_blank">mconley@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Yes, I'll update that document today.<br>
<br>
This is tremendous, kmag. Thank you for your work here!<br>
<span class="gmail-"><br>
On 2017-08-02 3:16 PM, J. Ryan Stinnett wrote:<br>
> Might be useful to list somewhere on the frontend practices page,<br>
> especially so these caveats are captured.<br>
><br>
> <a href="https://developer.mozilla.org/en-US/Firefox/Performance_best_practices_for_Firefox_fe_engineers" rel="noreferrer" target="_blank">https://developer.mozilla.org/<wbr>en-US/Firefox/Performance_<wbr>best_practices_for_Firefox_fe_<wbr>engineers</a><br>
><br>
> - Ryan<br>
><br>
> On Wed, Aug 2, 2017 at 2:11 PM, Kris Maglione <<a href="mailto:kmaglione@mozilla.com">kmaglione@mozilla.com</a><br>
</span><div><div class="gmail-h5">> <mailto:<a href="mailto:kmaglione@mozilla.com">kmaglione@mozilla.com</a>><wbr>> wrote:<br>
><br>
> In bug 1383367, I landed a set of new helpers to make it possible to<br>
> query the layout state (e.g., element size and position, or computed<br>
> style such as color) without forcing an uninterruptible reflow.<br>
><br>
> Note: Please read on for caveats before jumping into using this.<br>
><br>
> The one that you probably really care about is<br>
> promiseLayoutFlushed[1], which is in a lot of ways the converse of<br>
> (and complement to) requestAnimationFrame. Its use looks something<br>
> like this:<br>
><br>
> let width = await BrowserUtils.<wbr>promiseLayoutFlushed(document,<br>
> "layout", () => {<br>
> return elem.clientWidth;<br>
> });<br>
><br>
> requestAnimationFrame(() => {<br>
> otherElem.style.width = `${width - 2*borderWidth}px`;<br>
> });<br>
><br>
> This will cause the layout width of an element to be queried as soon<br>
> as that's possible without a reflow (which may be immediately, or<br>
> just after some other code queries the layout state, or just after<br>
> the next paint), and then uses that width to update the DOM in the<br>
> next animation frame.<br>
><br>
> Essentially, as long as your `promiseLayoutFlushed` callback queries<br>
> the layout *but never alters the DOM*, and your<br>
> requestAnimationFrame callbacks alter the DOM *but never query the<br>
> layout*, all queries and updates should happen in groups, and we<br>
> shouldn't have any uninterruptible reflows. In theory, either of<br>
> these things on their own should be enough to guarantee that, but in<br>
> practice, we have a lot of legacy code that doesn't follow those<br>
> rules, so this is another tool in our toolbox to get us close to<br>
> that ideal.<br>
><br>
><br>
> Important caveats: *Please* be careful how you use this. And<br>
> especially keep in mind that there may need to be a paint before<br>
> your promise resolves and any dependent DOM updates happen. If<br>
> you're not absolutely sure that that won't result in glitchy UI<br>
> behavior, *please test carefully* to make sure that it doesn't.<br>
><br>
> At the moment, the implementation is fairly crude, and any callbacks<br>
> which need to be deferred happen after the next full reflow, even if<br>
> a full reflow isn't required. And there's no way to force deferred<br>
> callbacks to be handled before the next paint aside from forcing a<br>
> layout flush. It should be possible in the future, though, to<br>
> schedule an interruptible reflow just before the next animation<br>
> frame in cases where we know that's required, and trigger our<br>
> deferred callbacks before paint. If you have a particular need for<br>
> that, please let me know and I may be able to make it a higher priority.<br>
><br>
><br>
><br>
> [1]:<br>
> <a href="https://dxr.mozilla.org/mozilla-central/rev/ef9a0f01e4f68214f0ff8f4631783b8a0e075a82/toolkit/modules/BrowserUtils.jsm#702-729" rel="noreferrer" target="_blank">https://dxr.mozilla.org/<wbr>mozilla-central/rev/<wbr>ef9a0f01e4f68214f0ff8f4631783b<wbr>8a0e075a82/toolkit/modules/<wbr>BrowserUtils.jsm#702-729</a><br>
> <<a href="https://dxr.mozilla.org/mozilla-central/rev/ef9a0f01e4f68214f0ff8f4631783b8a0e075a82/toolkit/modules/BrowserUtils.jsm#702-729" rel="noreferrer" target="_blank">https://dxr.mozilla.org/<wbr>mozilla-central/rev/<wbr>ef9a0f01e4f68214f0ff8f4631783b<wbr>8a0e075a82/toolkit/modules/<wbr>BrowserUtils.jsm#702-729</a>><br>
> ______________________________<wbr>_________________<br>
> firefox-dev mailing list<br>
</div></div>> <a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a> <mailto:<a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.<wbr>org</a>><br>
> <a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/firefox-dev</a><br>
> <<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/firefox-dev</a>><br>
<div class="gmail-HOEnZb"><div class="gmail-h5">><br>
><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> firefox-dev mailing list<br>
> <a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>
> <a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/firefox-dev</a><br>
><br>
</div></div></blockquote></div><br></div></div>