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

431–440 of 801 posts

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

#431

Post by swah »

desertrider wrote: post #199
JustSomeNobody wrote: post #144

Earlier quoted context omitted.

Where are the Michael Abrash's of today teaching people how to write tight, fast code? Seems a lost art... Yes, I know, he's still around...

Luckily there are a few people that still care, just look at the response Handmade Hero has gotten.

Those videos on data oriented design were also very interesting: https://github.com/taylor001/data-oriented-design

The thing is, using C++ instead of React for mobile development of a simple application would probably make me miss deadlines... So we just stick to whats popular.

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

#432

Post by dom0 »

Paradigma11 wrote: post #384
MichaelGG wrote: post #284

Earlier quoted context omitted.

On the flip side, the new Windows "Metro" style calculator app takes several seconds to load ... and is less usable than the old calc.exe.

It takes maybe half a second on my 4 year old Core I5.

Which is still kinda impressive given that calc.exe starts in milliseconds.

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

#434

Post by thiht »

vvanders wrote: post #47
aphextron wrote: post #16

I simply cannot understand why Atom and VSCode are so popular. I get that they are extensible, but is that really worth the slowdown to you? If I need more features than a text editor, I use an actual IDE. Someone just posted some really embarassing benchmark numbers regarding this issue yesterday: https://github.com/jhallen/joes-sandbox/tree/master/editor-p... Note that Atom and VSCode are nearly 10x slower than all…

Because for certain languages like Rust it is an IDE. I was a bit surprised at those tests. It doesn't match my gut feel, VSCode is quite snappy for me.

Same for Go and typescript/React, there's no better IDE than VS Code.

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

#435

Post by Mister_Snuggles »

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…

> Powerful* text editors built on the web stack cannot rely on the OS text caret and have to provide their own.

Is there any reason that Electron couldn't provide an API that would expose the system caret in an OS-agnostic manner? Windows, for example, has an API[0] that can arbitrarily show the caret at a given point in the window. Sounds like something that would be useful to many apps and not get in the way for those that don't need it.

[0] https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...

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

#436

Post by dang »

omegote wrote: post #296

> Because you can write plugins in JS? Yeah, kind of. Sadly most developers have neither formal nor self-taught education about compiled programming languages and/or desktop development. They're only familiar with web-related programming, so if you only have a hammer, everything looks like a nail. Being a hardcore real-time desktop developer during the mornings and a freelance web developer in the afternoons, I hones…

Please don't post putdowns of entire classes of people. It's unsubstantive and leads to flamewars, as demonstrated by the below.

We detached this subthread from https://news.ycombinator.com/item?id=13940405 and marked it off-topic.

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

#437

Post by allendoerfer »

dragonwriter wrote: post #355
panic wrote: post #344

Earlier quoted context omitted.

Why invent a new standard? HTML is fine, CSS is fine. Most importantly, everyone understands it and can work immediately with it. In order to render HTML, CSS and JavaScript, you need an entire web rendering engine. A new standard would let us get by with a lot less.

> In order to render HTML, CSS and JavaScript, you need an entire web rendering engine. Getting to piggyback on V8 and Blink work is, I suspect, often a benefit rather than a cost in the eyes of developers of Electron-based editors. Sure, it's bigger resource load, but for use cases where the performance is acceptable, it's a lot less developer load to get the functionality out the door.

Until you have to reimplement even blinking cursors.

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

#438

Post by dang »

Klathmon wrote: post #342
omegote wrote: post #296

> Because you can write plugins in JS? Yeah, kind of. Sadly most developers have neither formal nor self-taught education about compiled programming languages and/or desktop development. They're only familiar with web-related programming, so if you only have a hammer, everything looks like a nail. Being a hardcore real-time desktop developer during the mornings and a freelance web developer in the afternoons, I hones…

Can we cut the "holier than thou" pretentious bullshit? Just because someone uses a different language, or solves different problems doesn't make them worse or any less "hardcore" than you. You are right, the average JS developer might not be able to instantly know the details about how to implement a text buffer, because they don't need to do that on a daily basis. You probably don't know the details about how to im…

This breaks the HN guidelines about civility and not calling names in arguments. Please don't respond to a bad comment with an even worse one.

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

#439

Post by thiht »

aphextron wrote: post #43
allover wrote: post #34

Earlier quoted context omitted.

As was pointed out numerous times in that thread, they aren't 'embarassing benchmark numbers', they are 'irrelvant benchmark numbers', because no such 'slowdown' is actually felt by most developers that try VS Code. > But they have no place in text editing. Their popularity proves otherwise.

>they are 'irrelvant benchmark numbers', because no such 'slowdown' is actually felt by most developers that try VS Code I don't think that's true at all. I have tried both VSCode and Atom, and immediately dropped them both after they crashed opening a file of a few thousand lines.

That's not the use case of people using full featured editors.

For the same reason I don't open log files with Intellij or Visual Studio, I don't open them with VS Code.

I use VS Code as a code editor, not as a text editor. If I want to open a log file, I use Sublime or Vim.

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

#440

Post by Cpoll »

royjacobs wrote: post #427
krylon wrote: post #398

Earlier quoted context omitted.

Broken Sword let you play Breakout during the installation; it was such fun (I had not played Breakout in a long time at the point) I was almost sad when the installation was finished. ;-) I have often wondered since why this was not a more popular way to deal with long running installers.

Having minigames during loading or installation was actually patented by Namco for Ridge Racer, I believe. I'm not quite sure about the details since I seem to recall things like invade-a-load on my Commodore 64 at least a decade earlier, but there you go.

Expired in 2015 :)

When I was younger, it seemed so obvious to add a minigame to a long loading screen, I had assumed that there were technical reasons for not doing it.

Post reply on HN