https://taskcluster-artifacts.net/fNC0RNyLSkyC3I186Wim0g/0/public/logs/live_backing.log https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&selectedJob=171562324&filter-searchStr=Windows%2010%20x64%20QuantumRender%20opt%20Talos%20performance%20tests%20with%20e10s%20test-windows10-64-qr%2Fopt-talos-svgr-e10s%20T-e10s(s)

I'm disabling this, see https://bugzilla.mozilla.org/show_bug.cgi?id=1450552#c2 - we can use this bug to track re-enabling it.

The problem here seems to me that the idle request callback isn't getting fired. Not sure why yet, investigating.

I'm still digging into this but so far it looks like the test is running under ASAP mode, and that results in the refresh driver ticking so fast that it never has an "idle period". i.e. the function at [1] never returns `aDefault` which is what's needed in order to run the idle callback. It looks like WR off, the refresh driver ticks are sometimes longer (maybe because it's doing more work on the content side) and that provides a small window during which the idle callback gets to run. [1] https://searchfox.org/mozilla-central/rev/2b9779c59390ecc47be7a70d99753653d8eb5afc/layout/base/nsRefreshDriver.cpp#241

So I dug a bit more and confirmed comment 3 - that is, the requestIdleCallback mechanism doesn't play well with ASAP mode, in that there's no real guarantee as to when the idle callback will be triggered. So making those two work together would be one way to fix this. However, I'm not sure if it's worth messing with production code to fix a test-only issue (ASAP mode is only really used by tests). So I looked into why the requestIdleCallback mechanism was added, in bug 1372942. It is relevant for tests that load the same JS-heavy page multiple times. So we could just disable the requestIdleCallback mechanism on tests that only load a single page, because in those cases we know this mechanism is not going to provide any value. jmaher/rwood, do you have any thoughts on what you'd like to see done here?

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #4) > So I dug a bit more and confirmed comment 3 - that is, the > requestIdleCallback mechanism doesn't play well with ASAP mode, in that > there's no real guarantee as to when the idle callback will be triggered. So > making those two work together would be one way to fix this. However, I'm > not sure if it's worth messing with production code to fix a test-only issue > (ASAP mode is only really used by tests). > > So I looked into why the requestIdleCallback mechanism was added, in bug > 1372942. It is relevant for tests that load the same JS-heavy page multiple > times. So we could just disable the requestIdleCallback mechanism on tests > that only load a single page, because in those cases we know this mechanism > is not going to provide any value. > > jmaher/rwood, do you have any thoughts on what you'd like to see done here? What is ASAP mode and does it need to be enabled during the tests, or can that be turned off?

we use ASAP so we can measure the browser under stress, this was more useful than measuring page loads and waiting for events to happen. I see how requestIdleCallback can conflict with ASAP mode. I am fine with turning ASAP off for TART, but this should be a question for the current test owner :MattN.

I think having ASAP mode enabled here is valuable. It's the requestIdleCallback machinery that I think is not valuable. That being said I've been digging into the problem some more and I think that with non-WebRender the refresh driver does actually stop ticking at some points, and that might not be happening with WebRender. So I'll look into that aspect of it a bit more, it might be a bug.

So I chased down the problem with the refresh driver. What was happening is that the tart test opens a tiny window at the start. The client area of the window is 120x0, which caused WebRender to bail out of scene building at [1]. This meant that it never sent the DidComposite notification for that transaction back to the content side, and so the refresh driver was stuck in a "waiting for transaction" state. That window by itself was not really a problem, since the actual test runs in another window. But that refresh driver being stuck meant that the driver timer never went idle, and kept ticking as fast as possible, and that resulted in the idle callback never firing. What's supposed to happen is that once we reach a ready state, the refresh drivers all realize that there's no work, unregister themselves from the driver timer, and the driver timer should stop ticking. At that point the idle callback gets a chance to run, and the test advances. Modifying WebRender so that it handles 120x0 area more gracefully seems to fix the problem for me locally. Will do some more testing and try pushes to verify. [1] https://searchfox.org/mozilla-central/rev/00dd116638001772fe354b081353b73f1cad405d/gfx/webrender/src/render_backend.rs#178

https://treeherder.mozilla.org/#/jobs?repo=try&revision=d4d8c406caf3f724fbc8599e97dd161c1992649e is looking good.

Comment on attachment 8979683 [details] Bug 1451305 - Enable svgr talos on windows QR builds. https://reviewboard.mozilla.org/r/245828/#review251922 nice

Pushed by kgupta@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/2676c4241737 Enable svgr talos on windows QR builds. r=jmaher