Repository navigation
https://data.firefox.com/dashboard/hardware is extremely slow to respond to resize or zoom operations #409
Description
Activity
Nearly all of the work here seems to be calls to
getPointAtLengthfrom https://data.firefox.com/static/js/4.582265f3.chunk.js(Maybe the page is trying to do some sort of intelligent rescaling of its graphed data to the new viewport size, which ends up being more expensive than just rendering it in the first place? It's hard to know, since the JS here is pretty minified.)
Here's a profile captured in Firefox: https://share.firefox.dev/3Hlbyrg
...and in Chrome: https://share.firefox.dev/3rePWHaIn both profiles, there's ~10 seconds' worth of calls to
getPointAtLength.Reacted by HedgehogInTheCPPQuoting https://bugzilla.mozilla.org/show_bug.cgi?id=1999199#c4 from whimboo:
The problem here is actually that the page registers 11 event listeners for the resize event on the HTML element. All of them reference the exact same code in
/components/containers/ChartContainer.jsx:// Set the chart size state based on the real, rendered parent container. setChartSize = () => { const {width, height} = this.getChartSize(); this.setState({ chartWidth: width, chartHeight: height, }); }
Having only a single event listener active works just fine and resizes the graphs respectively with a way lower CPU load and just within 3.5s (Gecko profile). If there is further room for improvements I'm not sure and graphic folks might be able to answer.
But why are we registering 10 more listeners which basically run the exact same code and probably compete with each other?
Reacted by HedgehogInTheCPP
STR:
EXPECTED RESULTS:
The page should repaint with the new zoom level or viewport-size in about the time it takes for its initial rendering (around a second or less).
ACTUAL RESULTS:
On my pretty-fast Lenovo laptop, the page takes over 10 seconds to update its rendering (in Firefox as well as Chrome).
This issue is especially-bad in Firefox since it's long enough to trigger our slow-script notification (if you press any keys or attempt to scroll during the hang), and that notification itself triggers another viewport-resize which queues up another batch of the same slow work to happen again. See bug https://bugzilla.mozilla.org/show_bug.cgi?id=1750463. So instead of a 10-20 second hang, you can stretch it into an indefinite-duration hang (as long as you keep interacting with keypresses or scroll events during the hang).