Bugzilla

Now that the three things in comment 45 - comment 46 are fixed (thanks to tnikkel), testcases 2, 3, and 4 now consistently reports 600 - 640 milliseconds for me in Nightly.

Testcase 4 reports higher (worse) values in Chrome -- 700-900ms, and occasionally values in the ~1400ms neighborhood.
Testcases 2-3 are also  still consistently between 2 to 50ms in Chrome, though, I assume because of the possible optimization that I alluded to in comment 48.

Testcase 1 has improved a little bit for us, too, but not entirely. It reports ~3000-3300ms in today's Nightly, vs. ~4200ms in a Nightly from last week.

Updated profiles (reloaded the page to get 3 distinct loads in each case, to have more data):
- Testcase 1: https://share.firefox.dev/3pFEIgP
- Testcase 4: https://share.firefox.dev/3I8gO3R
(note, the reflows in these profiles are a bit higher than described earlier in this comment, presumably due to profiling overhead)

The profile of Testcase 1 shows that we're still spending ~30% of the reflow inside of `InvalidateDirectRenderingObservers` -- i.e. bug 1832684's fix isn't helping us there.  That makes sense, since in that case we are still doing a substantial amount of reflow after we've unsuppressed painting.  (We do an initial paint early on before we've reflowed the whole document.) That's probably the next low-hanging-fruit to fix here.

Now that the three things in comment 45 - comment 46 are fixed (thanks to tnikkel), testcases 2, 3, and 4 now consistently reports 600 - 640 milliseconds for me in Nightly.

Testcase 4 reports higher (worse) values in Chrome -- 700-900ms, and occasionally values in the ~1400ms neighborhood.
Testcases 2-3 are also  still consistently between 2 to 50ms in Chrome, though, I assume because of the possible optimization that I alluded to in comment 48.

Testcase 1 has improved a little bit for us, too, but not entirely. It reports ~3000-3300ms in today's Nightly, vs. ~4200ms in a Nightly from last week.

Updated profiles (reloaded the page to get 3 distinct loads in each case, to have more data):
- Testcase 1: https://share.firefox.dev/3pFEIgP
- Testcase 4: https://share.firefox.dev/3I8gO3R
(note, the reflows in these profiles are a bit higher than described earlier in this comment, presumably due to profiling overhead)

The profile of Testcase 1 shows that we're still spending ~35% of the reflow inside of `SchedulePaint` (which is mostly `InvalidateDirectRenderingObservers`) -- i.e. bug 1832684's fix isn't helping us there.  That makes sense, since in that case we are still doing a substantial amount of reflow after we've unsuppressed painting.  (We do an initial paint early on before we've reflowed the whole document.) That's probably the next low-hanging-fruit to fix here.