Open Bug 1278983 Opened 4 years ago Updated 4 years ago
Firefox performs relayout on mouse move causing site blinking
Is it possible to provide a reduced testcase with less CSS, SVG etc? (on http://codepen.io/ eg)
Regression range: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=11c3335d77fb751128c456daa204385d69678484&tochange=4de1094b41b27db10a5b0e5683ba4272c505ee9c Regressed by Bug 1255968, I guess.
Status: UNCONFIRMED → NEW
Component: Untriaged → Layout
Ever confirmed: true
Product: Firefox → Core
At least, I can reproduce the problem on Firefox22 (without e10s)
Setting layout.interruptible-reflow.enabled = false seems fix the problem. And, I think Bug 1255968 expose the existing bug of interruptible-reflow.
Due to the fact that the testcase has been provided updating the keywords.
Well. Interruptible reflow works like this: If the reflow takes too long we interrupt and paint as-is. That's the whole point of interruptible reflow. So the possible bugs here are: 1) We should not be reflowing at all. Not the case, since the clock is running, changing the DOM, needs relayout. 2) The layout should not take long enough for interruptible reflow to kick in. Interrupts never happen within the first 100ms of a reflow. I just checked, and on my hardware a full relayout of the comment 0 testcase, complete with box tree construction, etc, takes ~100ms. But the time taken for the clock running should be a good bit smaller, I would think. On the testcase in comment 3, a full relayout takes ~50ms over here, well under the 100ms threshold. Note that I don't see the flashing on either testcase, on Mac. The video is showing us basically making no progress on the reflow in 100ms or so, which is quite odd... Just to check, does running with the GECKO_REFLOW_MIN_NOINTERRUPT_DURATION environment variable set to a larger value than 100 (1000, say) help? How long does the relayout of this page take for you?
Tested on Nightly50.0a1 32bit e10s, Windows7 64bit with testcase of comment#0 GECKO_REFLOW_MIN_NOINTERRUPT_DURATION=2000 : reproduce GECKO_REFLOW_MIN_NOINTERRUPT_DURATION=2500 : not reproduce
Huh. Does a full relayout of that page really take over 2000ms on your hardware? Try this, in the console: var b = document.body; var s = b.style; s.display = "none"; b.offsetWidth; var start = new Date; s.display = ""; b.offsetWidth; console.log(new Date - start);
tested 3 times 1131 1141 1125
That's really weird. Why would you ever interrupt with a nointerrupt duration of 2000, then???
(In reply to Boris Zbarsky [:bz] (Out June 25-July 6) from comment #11) > That's really weird. Why would you ever interrupt with a nointerrupt > duration of 2000, then??? Probably, The CPU was busy due to another application (running 7-zip in background) when I test comment#8. Retest(without other application): GECKO_REFLOW_MIN_NOINTERRUPT_DURATION=1000 : reproduce GECKO_REFLOW_MIN_NOINTERRUPT_DURATION=1500 : not reproduce Sorry for the confusion.
OK, so that makes more sense. I'm still not sure why I'm not seeing this (on Mac). Certainly mouse move events are considered input events that should interrupt layout on Mac...
OK, so another performance test that might be relevant. Try this on the first testcase in this bug: var d = document.getElementById("clockDiv"); d.offsetWidth; var start = new Date; d.textContent = "hello"; d.offsetWidth; console.log(new Date - start); what gets logged? I'm seeing numbers on the order of 30ms here.
(In reply to Boris Zbarsky [:bz] (Out June 25-July 6) from comment #14) > OK, so another performance test that might be relevant. Try this on the > first testcase in this bug: > > var d = document.getElementById("clockDiv"); d.offsetWidth; var start = > new Date; d.textContent = "hello"; d.offsetWidth; console.log(new Date - > start); > > what gets logged? I'm seeing numbers on the order of 30ms here. 308 304 324
OK, I guess that's consistently 10x slower than my numbers. But that seems like a really suspiciously big performance difference to me...
(In reply to Boris Zbarsky [:bz] (Out June 25-July 6) from comment #16) > OK, I guess that's consistently 10x slower than my numbers. But that seems > like a really suspiciously big performance difference to me... Yep, My PC is 7years old. Core2Quad Q8300(2.5GHz, 2.0GHz in power save mode) + 8MB RAM + AMD HD6450
s/8MB RAM/8GB RAM/
You need to log in before you can comment on or make changes to this bug.