VS Code uses 13% CPU when idle due to blinking cursor rendering • Hacker News Board

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

#241

Post by parenthephobia » Thu, Mar 23, 2017, 4:29 PM UTC

dheera wrote: post #40

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…

Yep. I also can't wrap my head around the fact that we are now constructing buttons, drop-down boxes, tagged text boxes using dozens of nested layers instead of a native widget that writes directly to the screen. My 486 rendered UIs with nearly imperceptible lag. Google Docs takes a good 2-3 seconds to spin up a UI on my i7.

Separating layout from styling and behaviour is something that many GUI toolkit developers have decided is beneficial.

Most "modern" mainstream native toolkits - e.g. GTK+ 3, Qt 5, WPF - encourage this separation into layout - GtkBuilder, QML, XAML - and style - CSS, Qt Style Sheets, XAML Styles.

So, this isn't a "web browser" problem. Or, this style of GUI isn't the problem with Electron. I find GTK and Qt apps to be plenty responsive enough, even when their GUIs are loaded from XML files.

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

#242

Post by vetinari » Thu, Mar 23, 2017, 4:30 PM UTC

coldtea wrote: post #172

dvdcxn wrote: post #160

Earlier quoted context omitted.

I don't get this criticism. HTML/CSS is the closest we have to a universally understood syntax for designing interfaces. Why invent a new standard? HTML is fine, CSS is fine. Most importantly, everyone understands it and can work immediately with it. Any issues with performance is due to the implementation of the platform that renders this HTML/CSS interface. It's much more likely Google Docs feels sluggish due to th…

> Why invent a new standard? Because they suck?

There was XUL and it used native widgets.

XUL is dead now, HTML+CSS won.

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

#243

Post by thomastjeffery » Thu, Mar 23, 2017, 4:30 PM UTC

kitsunesoba wrote: post #217

dvdcxn wrote: post #160

Earlier quoted context omitted.

I don't get this criticism. HTML/CSS is the closest we have to a universally understood syntax for designing interfaces. Why invent a new standard? HTML is fine, CSS is fine. Most importantly, everyone understands it and can work immediately with it. Any issues with performance is due to the implementation of the platform that renders this HTML/CSS interface. It's much more likely Google Docs feels sluggish due to th…

Just because it's the best we have (if you're looking for a cross platform solution, anyway) doesn't mean that we've reached the peak and can just quit. We can do a hell of a lot better, and doing anything less is tragically underselling ourselves. There are no laws of physics preventing a better solution from existing. No, creating something better isn't easy, but neither have any of the other technological breakthr…

> it's the best we have (if you're looking for a cross platform solution, anyway)

No it's not. If you want a fast full-featured cross-platform GUI toolkit, there are many: GTK+ and Qt are especially great, and have bindings for several languages.

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

#244

Post by paulirish » Thu, Mar 23, 2017, 4:30 PM UTC

Touche wrote: post #41

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…

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 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.

(I work on the Chrome team, though not on the rendering engine)

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

#245

Post by voppe » Thu, Mar 23, 2017, 4:31 PM UTC

Philipp__ wrote: post #50

Touche wrote: post #35

Earlier quoted context omitted.

> 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.

Are you kidding me? Look at the raw performances and benchmarks of Vim/Sublime/Emacs, compare it to VSCode and Atom and you will see. If you don't believe the numbers then use both side by side, open 250MB file in all of them and look at the screen. And I still see native editors used more (for example latest StackOverflow survey, showed that Notepad++, Vim and Sublime combined are used much much more than VScode and…

Raw performance means nothing, it's just yet another metric that can be traded off in favor of other aspects that make up a good application. In VSCode's case, it was traded off in favor of ease of development, which spurred an extremely active and ever growing ecosystem of extensions. Was it worth it? The download counter says yes, because despite it being "slow" compared to other editors, the tradeoff is not even noticeable by most of its users.

This all boils down to the art of "it's good enough". Take game development for an example. You could write an engine from scratch using Vulkan APIs and all that jazz and run at 144fps@4k on a toaster. Or, you know, you could trade off the performance and settle for just using Unity and optimizing wherever possible. It's not as fast, but as long as the user is not frustrated by it, who cares? You just saved a lot of development time. Tradeoffs, tradeoffs.

Same thing applies here. The VSCode team did a damn good job of keeping performance just about over the "good enough" threshold of most of its users, unlike other Electron based applications. Of course, that threshold varies based on the user and his machine, but outright dismissing VSCode based solely on the assumption that editors cannot be written in html+js is simply short-sighted.

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

#246

Post by stinos » Thu, Mar 23, 2017, 4:31 PM UTC

8draco8 wrote: post #183

abritinthebay wrote: post #151

Earlier quoted context omitted.

VS Code is faster than Atom (by... a lot) tho? Especially with large files, but just in general. Speed is the main reason I can't stay using Atom for more than a few hours. It's awful. VS Code is snappier than Sublime Text ffs...

VSC is not even close of being as snappy as Sublime Text. Sublime also dominates when opening large files (2GB+) and searching trough them.

Agreed, except for the domination; true on linux afaik but not on windows: working with the large files is ok but opening them takes ages. VSC is definitely faster there.

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

#247

Post by Guillaume86 » Thu, Mar 23, 2017, 4:31 PM UTC

billconan wrote: post #111

Yesterday I wrote a webpage with a bootstrap template. The webpage has a progress bar that is updated in realtime by a websocket. The webpage is extremely slow. I guess every bit of progress bar update it rerenders the entire dom tree. I don't think react would do much better, but I will have to try.

With a decent implementation, a progress bar will run at 60 fps no problem. You don't need react for a simple progress bar either, just check no unnecessary is done (probably just need to update the width on an element) and use requestAnimationFrame if you receive updates at very high rate.

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

#248

Post by trimbo » Thu, Mar 23, 2017, 4:31 PM UTC

Philipp__ wrote: post #91

trimbo wrote: post #80

Earlier quoted context omitted.

This might mark the first time in history that Emacs was trotted out as an example of a performant editor. I say this as an Emacs user.

I am Emacs user. Have you tried it lately? It is lightning fast compared to Atom/VSCode. It's not as fast as Vim, struggles with long lines, and all that, but boy how surprised I when I uninstalled VSCode and fired up Emacs after a week of usage of VSc.

> Have you tried it lately?

I would, but it's still swapping back into RAM.

(For real though: yes, I use it all day)

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

#249

Post by simion314 » Thu, Mar 23, 2017, 4:32 PM UTC

dvdcxn wrote: post #177

coldtea wrote: post #172

Earlier quoted context omitted.

> Why invent a new standard? Because they suck?

Care to argue why? Also, there are countless alternative languages to compile down to HTML or CSS available. Feel free to create your own if none agree with your personal leanings.

CSS has many weird is corner cases where you have an issue and after a lot of debugging, trying things, getting mad you find on Stack Overflow that you add a ilogical rule like "min-width:0", so css is ok until you end up in a tricky problem where you need to understand how the css code works under the hood to fix. Other issue with css is too big and complicated, good layout modes are added but we stil ahve the old ones and you need to understand everything because most developers work on existing code and you hit all kind of layouts like floating,absolute,relative. Flexbox layout seems better but stil worse then layouts I have seen in MXML and WPF. So ignoring JS that you could replace, getting a new GUI for the Web inspired by MXML/WPF or QML with a sane subset of css would improve the situation.

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

#250

Post by digi_owl » Thu, Mar 23, 2017, 4:32 PM UTC

braveo wrote: post #167

jacquesm wrote: post #152

Earlier quoted context omitted.

> When Windows was developed, we had enough CPU power to do the basic tasks people wanted done with a computer at a reasonable speed - the idea was that spare capacity was being traded for user friendliness. And in many cases that led to an instant drop in productivity. Those old green-screen systems were not pretty but they were quite efficient to use.

I've actually witnessed a very large oil & gas company switch over from those old dos programs to a new win32 program, and to a man, every person who had any experience on the old system bitched about how much slower it was to get anything done. Having worked on the system myself, they were right (this was as a noobie to both systems). There is something to be said for a small, tight system.

Some time ago HN linked to a blog from a Norwegian tasked with mailing 3.5" floppies to doctors.

This because the doctors insisted on using a DOS based patient journal, as they could operate it completely by keyboard while maintaining a conversation with the patient.

I speculate that one reason for this is that DOS allowed each program to have full keyboard access, while Windows and other GUI has to reserve certain keys for managing the UI (switching between windows etc).

Thus what was earlier a series of single key presses now involves holding down a modifier for the duration. And that is if the developer even remembered to put in a hotkey for said action.