Issue metadata
Sign in to add a comment
|
Dev Tools performance issues on devices with HiDPI displays
Reported by
slava.no...@gmail.com,
Mar 28 2018
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 Steps to reproduce the problem: 1. Open up Chrome 61+ on an iMac with a 5K display. 2. Navigate to any web page. 3. Open Dev Tools. 4. Resize browser window or highlight elements. What is the expected behavior? • When resizing the browser window, the web page should reflow/repaint as smoothly as it does while Dev Tools isn't open. • When highlighting elements (either in the DOM inspector, or on the web page when using the in-page highlighter), it should as smoothly as when doing so on a non-HiDPI display. What went wrong? • When resizing the browser window, there is a significant delay for reflow/repaint, accompanied by huge spikes in CPU/GPU usage. • When highlighting elements (either in the DOM inspector, or on the web page when using the in-page highlighter), there is a significant delay between hovering an element and it being highlighted, accompanied by huge spikes in CPU/GPU usage. Did this work before? Yes 60 Chrome version: 65.0.3325.181 Channel: stable OS Version: OS X 10.13.0 Flash Version: • This issue persists all the way up to 67. • It doesn't matter whether the Dev Tools are within the browser window or detached in their own window. • In my desperation to fix this problem, I did a clean install of OS X with a new installation of Chrome, but the issue persisted. • It happens on both my home and work computers (both 5K iMacs), as well as on my coworkers' Retina MacBooks. • This expands upon #775019 (https://bugs.chromium.org/p/chromium/issues/detail?id=775019), which incorrectly asserted that the highlighting issue only occurs after resizing the browser window (it happens regardless of whether the window has been resized or not). There has also been no activity on that issue since the bug was reported shortly after 61 was released, and I don't think it was communicated clearly that this bug is specific to Macs with HiDPI displays. • There is also an ongoing discussion of this issue on Google Groups (https://productforums.google.com/forum/#!topic/chrome/C7OGUOxhuL0). Just to give a bit of extra context, I have been dealing with this bug all day, every day since 61 was released (5 months ago), and it's made front-end work extremely time consuming. I avoid using the element highlighting completely, but I still inadvertently move my mouse over the DOM inspector, which makes my computer fans to spin up and I have to wait while it goes through and highlights each of the elements my mouse moved over. If I need to work on anything relating to responsive styles, I just have to close Dev Tools. I completely understand that issues must be dealt with on a priority basis, but Chrome's Dev Tools are touted as the industry standard and should work regardless of my display's resolution, especially considering this wasn't an issue pre-61. Please, please give this a higher priority than the one assigned to #775019, I am beginning to lose my mind over this.
,
Mar 28 2018
Also I think that this effect becomes more extreme after some period of time (lets say few hours), so hovering elements in dev tools takes a second or two to register, which is really annoying. If I restart Chrome it goes back to being a little bit more responsive, but still very slow. iMac 5k Retina Mid 2015 Chrome 65.0.3325.181 (Official Build) (64-bit)
,
Apr 3 2018
This issue is marked as a release blocker with no milestone associated. Please add an appropriate milestone. All release blocking issues should have milestones associated to it, so that the issue can tracked and the fixes can be pushed promptly. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 6 2018
This issue is marked as a release blocker with no milestone associated. Please add an appropriate milestone. All release blocking issues should have milestones associated to it, so that the issue can tracked and the fixes can be pushed promptly. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 11 2018
I also just would like to add to and confirm I have this issue as well after updating Chrome. Major workflow hick-up that is making me have to switch browsers and lost time in development.
,
Apr 16 2018
I have had this issue for awhile on various computers (non apple btw), and had no idea why it was being slow. I finally looked up bug reports for it and realized that it has to do with my HiDPI displays. I have a 4k screen hooked up to two computers. One with windows and linux (Ubuntu 16.04), and the other with windows. It is super slow on all three. I also have a laptop with a 3k screen and linux, and it is also slow. This seems to affect anything with HiDPI at all, irrespective of actual resolution or operating system. I found what might be the issue in another bug report about the devtools being slow (#821020). Most HiDPI displays (at least that i've seen) use YCbCr or something instead of the "standard" RGB. Since it's in a different color space, chrome has to color correct everything, and is apparently not doing that very efficiently. This would cause the lag that's seen. https://bugs.chromium.org/p/chromium/issues/detail?id=821020
,
Apr 17 2018
I think you are right on the money with that one – switching my display's colour profile to sRGB has completely alleviated the lag I experience when inspecting elements. There is still some delay when resizing the window, but it's infinitely better. I can't tell you how relieved I am to have working Dev Tools again, thank you so much for the heads up!
,
Jul 25
,
Dec 4
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by pfeldman@chromium.org
, Mar 28 2018Labels: ReleaseBlock-Stable
Owner: junov@chromium.org
Status: Assigned (was: Unconfirmed)