Rendering performance when using Grid-Layout in 67 (fixed in 68?)
Reported by
fpiew...@gmail.com,
Jul 18
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36 Steps to reproduce the problem: 1. Download the code example and open it with Chrome 67 2. Go to Performance in DevTools 3. Click on record 4. Click on the button named “FORCED REFLOW” 5. Click on stop 6. Do the same again and replace step 4 with page reload What is the expected behavior? What went wrong? In this case of forced reflow, rendering took ~270ms. I also measured rendering time when loading the page (step 4 is replaced by reloading the page), which was ~910ms. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 67.0.3396.99 Channel: stable OS Version: Fedora 27 Flash Version: We use the Grid-Layout (display:grid) and it seems that the rendering-performance decreases rapidly if you use this layout within a complex layout (e.g. large DOM, many nested grids). However, even in very small pages (as the example that I included), the performance is rather bad. The bug is furthermore quite difficult to reproduce as it does always not appear when using layout grid and I did not manage to blame a certain CSS property that might cause the problem in combination with the grid-Layout. The whole problem does not appear in the Chrome beta Version (Chrome 68) (and also not in Firefox 61.0). The rendering time when loading the page is less than 40ms in Chrome 68, and less than 20ms rendering time for the forced reflow. As the problem does not appear in Chrome 68, I concluded that the problem might already be fixed. However, I did not find any information about this in any previous Bug reports or official release notes. As my company uses the grid Layout, it would be fatal for us, if such a bug would appear again in the future.
,
Jul 20
Thanks for filling the issue... Unable to reproduce the issue on reported chrome version 67.0.3396.99 using Ubuntu 17.10. Attaching screenshot for reference. Steps: --------- 1. Launched reported chrome >> Downloaded html file and opened on new tab 2. Navigated to Dev_tools >>Performance >>Clicked on record 3. Clicked on the button “FORCED REFLOW” >>Clicked on stop 4. Repeated again and replaced step 4 with page reload As we are seen rendering values as screenshots @Reporter: Could you please review the attached screenshots and also confirm this issue and also confirm issue related to Fedora 27. Thanks.!
,
Jul 20
Thank you for your answer! Actually, you reproduced the issue! In your screenshot, the rendering time is 322.2ms for "forced reflow" and 3065.2ms for reloading. So, the rendering performance is quite bad in the stable version of Chrome (Chrome 67).
,
Jul 20
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 23
Javier, are you aware of any performance problems for grid in 67 or fixes since? If this was a real regression or a real performance improvement it would be great to add a test for it to ensure it doesn't regression going forward. Thanks!
,
Aug 13
It's true that we recently added several changes that could have impacted performance, both positively and negatively. I'll have to investigate it carefully to determine if one of the changes we made that may have regressed could be fixed. As I said, we've just landed important changes in how we manage the grid data structures that could make difficult to figure out the fixable regressions, but I'll give it a try.
,
Aug 14
This is he first perf regression I found out, which is likely caused by one of our last changes in the grid layout algorithm: https://chromeperf.appspot.com/report?sid=a59eac6929f7bc6f1c795ae6d28fa8b219931447d2a8e8f5484e27fcaa68936b&start_rev=554053&end_rev=569878
,
Aug 14
This is the change that most likely caused the regression: https://chromium-review.googlesource.com/c/chromium/src/+/923261
,
Aug 14
I tried to bisect the test case behind Chrome 67 (67.0.3396.99) and Chrome 68 (68.0.3440.106 - current stable) and this is the result: You are probably looking for a change made after 551077 (known bad), but no later than 551086 (first known good). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/6314d4ac104a415d2951b94c989fbadb2bdb62b5..7e17239b41ba20e52752982d95fe9f7105289f97
,
Aug 14
From the info above, I found out that this change, which is fixing an important performance regression: https://chromium.googlesource.com/chromium/src/+/1f4159ae4aa6d85d967bc4f96b3305e4a2f8ac31 The above mentioned regression (# issue 832078 ) was introduced in #r549461, which initially landed in Chrome 67.0.3394.0, so it was still affecting the version described in this report.
,
Aug 14
My opinion is that this issue has been already fixed in 68 and it was properly detected (# issue 832078 ) by the current performance tests. I was unable to reproduce the issue in latest dev channel (70.0.3514.0), so I think we can close this bug now.
,
Aug 14
,
Aug 17
,
Aug 18
Okay, sounds good! Thank you very much!
,
Aug 28
Closing now then, please, reopen if it's reproducible in versions above M68. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by viswa.karala@chromium.org
, Jul 18