CPU usage even when idle (due to cursor rendering)

[joliss]

• VSCode Version: 1.10.2 (8076a19)
• OS Version: macOS Sierra 10.12.3

VS Code uses 13% CPU when focused and idle, draining battery. This is likely due to the blinking cursor rendering. I think CPU usage when focused-and-idle could ideally be near-0%.

To reproduce (this works with an empty settings file and all plugins disabled):

1. Close all VS Code windows.
2. Open a new window (File -> New Window). It will show the Welcome page.
3. Open a new tab with an empty untitled file (File -> New Tab). The cursor is blinking.
4. You should see VS Code consuming a non-negligible amount of CPU -- 13% on my 13" MacBook Pro.
5. Cmd+Tab into some other application. Now the cursor isn't visible anymore.
6. You should see VS Code consuming virtually no CPU.

I recorded a Timeline in the Developer Tools, and a cursory look suggests that the CPU activity comes from rendering the blinking cursor every 500ms.

Other macOS applications like Chrome or TextEdit show a blinking cursor without consuming much CPU, so I think this could surely be optimized away.

[joliss]

A workaround for folks who are similarly obsessed about battery life: Disabling cursor blinking will make CPU usage drop to 0. Here's the setting:

  "editor.cursorBlinking": "solid"

[joliss]

Some people on Twitter said they couldn't reproduce this, so I went and recorded a timeline in the Developer Tools to help debug.

TimelineRawData-20170321T114212.json.zip

• Screenshot of the timeline:

  

• Zooming into a single frame, we see that while we render only 2 fps, the main thread is performing some work at 60 fps (every 16 ms) -- the thin lines marked with arrows:

  

• Zooming all the way into one of those thin lines, we see that some rendering is happening at 60 fps:

  

• When I take a CPU profile, it shows most CPU being spent in "(program)", not any specific JS function.

  

• When I set "editor.cursorBlinking": "solid", the problem mostly goes away: A periodic "Update Layer Tree" / "Paint" / "Composite Layers" is still happening, but only every 500ms, not every 16ms.

I hope this helps!

[rebornix]

Jo Liss (@joliss) Quick answer to what's happening under the hood: a native animation updates at 60hz in Chromium.

Similar (almost the same) Chromium issue https://bugs.chromium.org/p/chromium/issues/detail?id=500259 and Chromium's tracking item https://bugs.chromium.org/p/chromium/issues/detail?id=361587

Our current CSS animation

@keyframes monaco-cursor-blink {
	50% {
		opacity: 0;
	}
	100% {
		opacity: 1;
	}
}

.cursor-blink {
	animation: monaco-cursor-blink 1s step-start 0s infinite;
}

Update

Quoting Paul Irish (Chrome guy) https://news.ycombinator.com/item?id=13941293

Powerful* text editors built on the web stack cannot rely on the OS text caret and have to provide their own.
In this case, VSCode is probably using the most reasonable approach to blinking a cursor: a step timing-function with a CSS keyframe animation. This tells the browser to only change the opacity every 500ms. Meanwhile, Chrome hasn't yet optimised this completely yet, hence http://crbug.com/361587.
So currently, Chrome is doing the full rendering lifecycle (style, paint, layers) every 16ms when it should be only doing that work at a 500ms interval. I'm confident that the engineers working on Chrome's style components can sort this out, but it'll take a little bit of work. I think the added visibility on this topic will likely escalate the priority of the fix. :)

• Simple text editors, and basic ones built on [contenteditable] can, but those rarely scale to the feature set most want.

[graymalkin]

Will this change about background CPU usage of chromium tabs affect the editor?

[bpasero]

Hopefully not (see electron/electron#7553). We do set backgroundThrottling to false since a while already.

[alexdima]

Thank you Jo Liss (@joliss) Peng Lyu (@rebornix) for the nice analysis.

Looks like we should go back to using setInterval on OSX.

p.s. Here's the initial cursor blinking logic :)

[bcherny]

Peng Lyu (@rebornix) Here's a similar issue we ran into a while ago - https://bugs.chromium.org/p/chromium/issues/detail?id=658894. The workaround in our case was to remove the animating element from the DOM when it was not used, rather than just occluding it.

[sunnykgupta]

Link to the current implementation -
https://github.com/Microsoft/vscode/blob/master/src/vs/editor/browser/viewParts/viewCursors/viewCursors.ts

[sunnykgupta]

There is also a css style for the same, not sure if it is used here though -

@keyframes monaco-cursor-blink {
	50% {
		opacity: 0;
	}
	100% {
		opacity: 1;
	}
}

https://github.com/Microsoft/vscode/blob/master/src/vs/editor/browser/viewParts/viewCursors/viewCursors.css