Huge memory usage after resizing frequently
Reported by
zhanzhen...@hotmail.com,
Nov 20 2016
|
||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/602.2.14 (KHTML, like Gecko) Version/10.0.1 Safari/602.2.14 Steps to reproduce the problem: When using a script to change the font size on "window resize" event, and then resizing the window's height frequently, you'll see the memory usage of "Google Chrome Helper" process rapidly increases. From 150MB to around 400MB. See this example: https://jsfiddle.net/cb254p8m/1/ (Please only resize the height, since the font size depends on the height) Even if I use a CSS constant, for example, "5vmin", and don't use the "onresize" event, this issue still exists, see: https://jsfiddle.net/cb254p8m/3/ What is the expected behavior? Like in all other browsers, the memory usage should not rapidly increase. What went wrong? The memory usage rapidly increases. Did this work before? N/A Chrome version: 54 Channel: stable OS Version: OS X 10.12.1 Flash Version:
,
Nov 21 2016
,
Nov 25 2016
Unable to reproduce the issue in Mac 10.11.16, Windows-10 and Ubuntu 14.04 by using chrome reported version #54.0.2840.98 and latest canary #57.0.2931.0. Steps followed to reproduce the issue are as follows: ----------- 1. Navigated to URL: https://jsfiddle.net/cb254p8m/1/ 2. Resized the window's height frequently. 3. Opened the chrome task manager and observed that the memory usage did not rapidly increase, rather it remained at 200 to 250MB. Attaching screen cast for reference Reporter@ - Could you please check this issue on latest canary #57.0.2931.0 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not. Thanks...!!
,
Nov 25 2016
Please use macOS's Activity Monitor instead of Chrome's internal tool. The process is "Google Chrome Helper".
,
Dec 2 2016
Still "Unconfirmed"? Yes the Chrome's internal monitor doesn't show this. But you can reproduce it using macOS's Activity Monitor.
,
Dec 12 2016
Thank you for providing more feedback. Adding requester "krajshree@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 28 2016
Still unable to reproduce the issue in Mac 10.12.2 by using chrome reported version #54.0.2840.98, latest stable #55.0.2883.87 and latest canary #57.0.2964.0. Steps followed to reproduce the issue are as follows: ----------- 1. Navigated to URL: https://jsfiddle.net/cb254p8m/1/ 2. Resized the window's height frequently. 3. Opened the activity monitor in mac and observed that the memory usage did not rapidly increase, rather it remained at 70 to 75 MB. Attaching screen cast for reference zhanzhenzhen@ - Could you please check this issue on latest stable #55.0.2883.87 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not. Thanks...!!
,
Dec 28 2016
Please check my screen recording. I am on the latest stable. I have no plug-in or extension installed.
,
Dec 28 2016
I even created a new user to test, but this issue persists.
,
Jan 4 2017
Thank you for providing more feedback. Adding requester "krajshree@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 5 2017
Still unable to reproduce the issue in Mac 10.12.2 by using chrome reported version #54.0.2840.98 and latest canary #57.0.2971.0. Steps followed to reproduce the issue are as follows: ----------- 1. Navigated to URL: https://jsfiddle.net/cb254p8m/1/ 2. Resized the window's height frequently. 3. Opened the activity monitor in mac and observed that the memory of process "Google Chrome Helper" did not rapidly increase. It increased and remained at 161 MB and fluctuated within 161 MB. Attaching screen cast for reference zhanzhenzhen@ - Could you please check this issue on latest canary #57.0.2971.0 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not. Thanks...!!
,
Jan 6 2017
I've just found why you can't reproduce it. This is because your Chrome's default font is maybe a Latin font. When I use a Latin font I also can't reproduce. My macOS and Chrome are both in Simplified Chinese so the default font is "黑体-简" (its formal English name is STHeiti). I guess this font is in all macOS versions so I've created a new fiddle for you to test: https://jsfiddle.net/cb254p8m/4/ Good news is that I found in Chrome 57.0.2974.0 this issue disappeared! But in the stable version 55 it still exists. So please test that on v55.
,
Jan 6 2017
Some Asian fonts have this issue, while some don't. When I research them in macOS's Font Book, it seems only "TrueType" asian fonts (but not "OpenType TrueType" asian fonts) have this issue.
,
Jan 6 2017
I guess why Chinese fonts can trigger this problem is because their font files are huge.
,
Jan 6 2017
I found when testing, if it slides very smoothly (I mean at 60 fps), then this font doesn't have this issue. But when it's only 30 fps or less, then most probably it has.
,
Jan 16 2017
Thank you for providing more feedback. Adding requester "krajshree@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 31 2017
Hi krajshree, Could you please have a look at my comment #12?
,
Feb 17 2017
zhanzhenzhen@ - Could you please check this issue on latest stable #56.0.2924.87 and please let us know if the issue still persist.
,
Feb 17 2017
Yes, just checked the latest stable 56.0.2924.87 and this issue persists.
,
Feb 19 2018
Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by zhanzhen...@hotmail.com
, Nov 20 2016