New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 695159 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Jan 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug



Sign in to add a comment

Keep extension burns CPU with needless icon updating

Project Member Reported by shrike@chromium.org, Feb 22 2017

Issue description

Chrome Version: 57.0.2987.37
OS: macOS 10.12

What steps will reproduce the problem?
(1) Install the Keep extension
(2) Turn on flash screen updates in Quartz Debug

What is the expected result?
No activity in the browser window, which should mean no activity in the toolbar

What happens instead?
The Keep icon is getting redrawn about once every 3 seconds. OS X ends up invalidating a larger area of the window, so the total area redrawn is not insignificant. There is no change in the appearance of the Keep icon so all of this work is for naught.

There's a call to extensions::ChromeExtensionWebContentsObserver::OnMessageReceived that kicks off the redraw (see the attached trace). rdevlin.cronin@ - can you explain what's happening here in this backtrace? I guess the extension is updating itself on every message (not sure what that is) received by the web contents. If you can step me through what the extension is doing that would be very helpful. Ultimately this is a Keep problem, but there may be optimizations we can make in Chrome that can help. Ultimately I want to file a bug against Keep but I need to know what they are doing wrong.

 
KeepExtensionBurningCPU.txt
480 KB View Download
Cc: shrike@chromium.org
Basically, all that's going on is that Keep seems to be continually calling chrome.browserAction.setIcon [1].  Most of that flow is the normal extension API method route - the renderer dispatches an IPC method, which is received by the ExtensionWebContentsObserver, and then routed to the proper ExtensionFunction via the ExtensionFunctionDispatcher (lemme know if you want code pointers to these, or to chat over gvc for a few minutes - it's a little complicated, but 99% of extension functions take this same flow).

Once the browser action icon is updated, we dispatch a notification, and redraw the icon.

Since the icon isn't visually changing, it seems like keep shouldn't be calling the API method as the first and most important fix.

On the chrome side, there are a few things we could do.  One would be check to see what the current icon is - if they're specifying the icon by path, we might be able to just do a check to see if it's the same path as was last set.  Otherwise, if it's pure image data (as from a canvas), it's potentially possible that we could do a bitmap diff to see if anything changed.  Unfortunately, that would slow down the common/good use case (when the API is only called as-needed), but it would obviate a bunch of churn if the icon is in fact the same.  (However, at some point, there's only so much we can do - if there's a pixel difference and it's just imperceptible, we'd still update the icon.)

[1] https://developer.chrome.com/extensions/browserAction#method-setIcon
Labels: -Pri-2 Pri-3
Is there anything we can do to fix this aside from reaching out to the Keep team?

Comment 3 by shrike@chromium.org, Aug 25 2017

Cc: -shrike@chromium.org rdevlin....@chromium.org
Owner: shrike@chromium.org
I had as a to do for a long time to file a bug against Keep for excessive updates, but when I finally got around to it I could not repro. Assigning to myself to check again - I'll either then file a bug against Keep or close out this one.

Comment 4 by shrike@chromium.org, Jan 24 2018

Status: WontFix (was: Assigned)
Last time I checked the issue no longer existed.

Sign in to add a comment