Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

VS Code uses 13% CPU when idle due to blinking cursor rendering

github.com

Post reply on HN
Print view View original

331–340 of 801 posts

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#331

Post by dualogy »

Philipp__ wrote: post #14

It just doesn't go in my head that we are building text editors inside a web browser! I get it, there are many good use cases for Electron and it's easy to get started with cross platform support, but why is everybody going crazy about text editors in them? Because you can write plugins in JS? Wouldn't it be better to make native application, especially for code editors, where developers spend most of their time, whe…

> It just doesn't go in my head that we are building text editors inside a web browser!

I felt the same until I actually tried it out. That changed my mind: now I'll take any platform that those developers & contributors choose for their cross-platform products. Because this for an Electron app, this is a rock-solid 'old-school' (as in, fully as neat smooth helpful-yet-staying-out-of-the-way and somehow "ergonomic" as it was ever since at least oh late 90s, v6 or so) "Visual Studio experience". After a few years of sitting listlessly in front of subjectively inferior editors, I'm prepared & willing to give this Electron stuff more time to further mature improve and speed up. There's no intrinsic reason it can't get there. Lots of seemingly native apps are just live Lua/Python interpreters under the hood with widget bindings in place of a DOM. In that case, well-engineered JavaScript (terribly time-consuming to produce & pretty rare out there for those who like to rely blindly on a huge pile of unscrutinized 3rd-party snippets/script um-I-mean "repos" --- but not impossible) can fully deliver the same, in principle.

Seeing how VScode took off, that could even propel MS to invest unprecedented energies & talent into rounding up the JS "rich client app" performance story further. Who knows.

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#332

Post by criddell »

Touche wrote: post #35
Philipp__ wrote: post #14

It just doesn't go in my head that we are building text editors inside a web browser! I get it, there are many good use cases for Electron and it's easy to get started with cross platform support, but why is everybody going crazy about text editors in them? Because you can write plugins in JS? Wouldn't it be better to make native application, especially for code editors, where developers spend most of their time, whe…

> Wouldn't it be better to make native application Better in what way? The market has voted with their downloads, they don't agree that the problems with Electron apps are as bad as you feel that they are.

Unless you enjoy the sound of your fan and battery life of only a couple hours, 13% CPU to blink the cursor is a problem.

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#333

Post by logicallee »

You know how there's like, hard real time embedded programming where if you don't hit your realtime deadline every time without exception forever, your engine explodes or something?

Well, apparently the web is built on whatever the opposite of that style of programming is.

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#334

Post by Kristine1975 »

paulirish wrote: post #244
Touche wrote: post #41

Earlier quoted context omitted.

I think I don't understand the issue well enough. This looks like a standard blinking cursor to me. Users expect a blinking cursor in an editable text field. I'm not sure why this implementation is slow or why they needed to implement it themselves and not let the OS handle the blinking cursor. I'm guessing there must be some reason.

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 curren…

>http://crbug.com/361587

Reported almost 3 years ago and still not fixed...

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#335

Post by pcwalton »

paulirish wrote: post #244
Touche wrote: post #41

Earlier quoted context omitted.

I think I don't understand the issue well enough. This looks like a standard blinking cursor to me. Users expect a blinking cursor in an editable text field. I'm not sure why this implementation is slow or why they needed to implement it themselves and not let the OS handle the blinking cursor. I'm guessing there must be some reason.

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 curren…

Why are you even painting at all instead of layerizing it?

(This is a perfect example of what I've been increasingly convinced of lately: that the whole "paint"/"compositing" distinction hurts the Web…)

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#336

Post by oblio »

tomc1985 wrote: post #322
oblio wrote: post #309

Earlier quoted context omitted.

Do you know of a "more appropriate" language for creating cross platform apps that work on Windows, Linux, MacOS, BSDs, iOS, Android, 4k screens and 480p screens? I don't know any.

C? C++? QT? Java? Any language with GTK hooks? Xamarin? Juce framework? Delphi?? You say 4K and 480p screens like that's hard. Design once, scale forever?

C is unsafe and is too low level.

C++ is possibly the only language with more bad parts than Javascript :)

Java ok, but how would you run it on iOS? The last viable option for that (RoboVM) was taken behind the shed and shot by Xamarin/Microsoft.

GTK doesn't run on mobile and it's barely supported on Windows and MacOS.

Xamarin is ok, but it used to be closed source and cost $1000 per year for any serious project.

I don't know Juce, but from what I can see it's a C++ framework, so see C++ :)

Delphi? Zombies don't count ;)

The most viable contenders for modern cross platform software were marred by bad corporate ownership: Java, C#. They've kind of gotten back on track recently but I'm not sure they can catch up to the web-train.

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#338

Post by jcwayne »

artursapek wrote: post #25

I'm reminded of this classic: https://github.com/npm/npm/issues/11283 NPM had a progress bar that was so fancy that it slowed down installation time (basically its only job) by ~50%. Hilarious. My mantra here is, if you find yourself thinking about implementing a fancy loading spinner/progress bar, it would be more productive to just spend that time making it unnecessary - speed up your shit! Obviously that doesn't a…

In the early days of working on my current main project, I found that updating a progress bar was slowing the process it was monitoring. Since there were times when it was useful to see near real-time progress, I added added a slider which allows the user to adjust the sampling rate. That slider is affectionately known (by me anyway) as the Heisenberg Compensator.

P.S. I have sped up my shit. That process originally took days, now it takes an hour.

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#339

Post by sigzero »

Philipp__ wrote: post #14

It just doesn't go in my head that we are building text editors inside a web browser! I get it, there are many good use cases for Electron and it's easy to get started with cross platform support, but why is everybody going crazy about text editors in them? Because you can write plugins in JS? Wouldn't it be better to make native application, especially for code editors, where developers spend most of their time, whe…

No, you are correct. It is insane.

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#340

Post by gpderetta »

mmarks wrote: post #56

13% cpu usage at the lowest c-state is a also very different than 13% at an elevated c-states. I've recently spent a lot of time analyzing c-states/p-states and the power mgmt modes of the GPU. After learning more about the complexity behind the clocks, bus speeds, etc. underlying each state, whenever I hear someone quote a utilization number of a minor workload, I want to know at what power state. Not to take away b…

That's actually even worse: it will prevent the cpu to enter deep sleep states and save more power.

A while ago I was trying to minimize the power usage of my laptop (yeah, slow day) to maximize my battery time.

Armed with powertop, I removed any undesired process until I was left with an otherwise idle emacs (less than 1<% cpu) as the last major source of wakeups. Sure enough, disabling the blinking cursor brought that down to nothing, allowing the cpu to stay into deep sleep state much longer.

Post reply on HN