Performance jank after viewport scroll with frequent `set` calls with Ember
Reported by
av...@wearestack.com,
Oct 13 2016
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36 Steps to reproduce the problem: 1. Download and setup application repo from https://github.com/averydev/chrome-perf-issue 2. In a new tab, go to http://localhost:4200 Don't scroll the viewport vertically 3. Open dev tools 4. On top graph, quickly drag brush back and forth. Lower graph, as well as date text fields should all respond very quickly 5. Scroll viewport vertically on top graph, again drag brush back and forth. Lower graph and date text fields appear to be going around 1-2 fps 6. Refresh tab 7. Brush top graph. Jank persists, through browser What is the expected behavior? Graphs and text fields should update smoothly on the order of ~30fps. What went wrong? There is a fierce performance degradation that effects both graph drawing but also simple text field updates. This behavior persists across tab refreshes, but will disappear in a new tab. When performance is impacted it appears to the user to be going around 2-3fps. The dev tools tell a different story, showing little CPU activitiy, rendering, fewer long frames, and relatively high fps in comparison to prior to scrolling Did this work before? N/A Chrome version: 53.0.2785.143 Channel: n/a OS Version: OS X 10.11.6 Flash Version: Shockwave Flash 23.0 r0 This is how the bug appears in the full application: https://monosnap.com/file/olMt4dFTVHqIe7RMKgfq6fQDpfmOw9 Note the fps drop effecting both the graph and the dates fields This can be very reliably reproduced with dev tools open: https://monosnap.com/file/HAM8ksgWyP00CIvEO3kPvLquztTJ8j However it can also be reproduced without them open, though it takes a bit longer. Once the jank is occuring, it survives page refreshes https://monosnap.com/file/WUvWoCnCV6HQ5zsDEBcHvVGadWCsyd Here is what a timeline looks like in the full application https://monosnap.com/file/4kob1Zeb8IESBp3JaFPT7PADFvczyN And video of that timeline being recorded: https://monosnap.com/file/wfMeBAAEU2Xsnprnlh8CP6KEn3VCix This is the exact opposite of what I would expect. This is a video of the
,
Oct 13 2016
Avery, is it possible to make the repro repo public so other people can have a look? It is really strange though that this behavior is not exposed to DevTools.
,
Oct 13 2016
Try https://www.chromium.org/developers/how-tos/trace-event-profiling-tool This should exactly tell you what event is causing jank.
,
Oct 13 2016
Hi all, Firstly, thank you for being so responsive to this issue. I created a private GH repo and invited everyone from the v8 team I could find, per Benedikt's request. Because this includes client code, to make it public, I would have to create new components w/o that code. I'm happy to do that if its needed, but it would save me time if you can use the private repo. If there are other specific people to add as collaborators, I'm more than happy to add. I can also publish the chrome-perf-issue app to Firebase or similar so that there is a live example if you don't need the actual source.
,
Oct 13 2016
I just downloaded Chrome 51 for Mac, and verified that this issue exists there as well. It is perhaps a little better than 53, but it's hard to compare...
,
Oct 13 2016
,
Oct 14 2016
avery, could you please do an analysis as mentioned in #3?
,
Oct 19 2016
,
Oct 20 2016
Hi all, My Chrome just updated to 54, and voila! I'm jank free! Thanks all!
,
Oct 21 2016
Thanks. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by bmeu...@chromium.org
, Oct 13 2016Owner: hablich@chromium.org