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

291–300 of 801 posts

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

#291

Post by yumaikas »

dvdcxn wrote: post #160
dheera wrote: post #40

Earlier quoted context omitted.

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.

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…

HTML and CSS are a bad fit for rendering heavy graphical interfaces because they fundamentally follow a document flow rather than grid-based layouts. Flexbox and css-grid are helping some in this area, but they are not used very often.

(not to say that HTML and CSS aren't useful, but they are far from the idea means of rendering a UI).

HTML does work fine when you use it for mostly document focused work, and I enjoy the interactivity and connectivity that web browsers have brought to the web, but I'd love to see an improvement on it all.

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

#292

Post by pyre »

scriptproof wrote: post #214
throwasehasdwi wrote: post #158

Earlier quoted context omitted.

Javascript is meh, it's HTML and CSS that are the real culprits for the crazy inefficient GUI rendering. HTML was great for what it was designed for, but we're ten years beyond that. Something will come in and replace HTML, it's just a matter of time. The main driver is mobile. The many layers of abstraction burn battery, one day phone manufacturers will get tired of it and do something.

Something like XUL, XAML or Enyo? Wait for it.

Something like React Native that targets Windows/macOs/Linux rather than iOS/Android? I think that this would be a better way to deal with using Javascript as the dev environment, while at the same time passing on Electron.

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

#293

Post by dahart »

ChuckMcM wrote: post #70

I love the irony of simulating an XOR gate from a piece of hardware (a serial terminal) with a billion gates in a processor which renders a square with an alpha blend function. Sort of like using a 787 to sit on the runway, and run its engines to blow a windmill to crank a butter churn :-).

That's a fun analogy, made me laugh. :)

I see this literally everywhere though, the article at hand is only a slightly better example than almost everything we do. Browsers consume gigabytes of memory to render a few basic web pages. We use high level scripting languages with tons of dynamic memory inside containers that are running on VMs to run all our cloud infrastructure. If we had the time, these things could be multiple orders of magnitude faster and smaller. It just isn't worth our time... :P

Another fun example of this I ran into recently is the controllers for brushless drone propellers. The hobby motors you buy for $20 usually have a 1Mhz 8-bit CPU running Electronic speed control, literally shrink-wrapped inside the wires. Every single prop. Think about that, a million instructions per second running, only to make something spin. (To be fair, the CPUs are under-utilized, but still, it reminds me of churning butter with a jetplane.)

The main difference, of course, is that cpu time & memory are close to free, and 787's are super expensive. Maybe if 787's were free, we'd use 'em often to churn butter... ;)

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

#294

Post by tomc1985 »

joshuamorton wrote: post #146
tomc1985 wrote: post #104

OH GOD NO Adding ANOTHER interpreted language to the pile? Jeeze you guys are crazy. Just STFU and learn C/Go/Java Does ANYONE in NodeJS world care about efficiency? Or does this "plebian" (ew! hacking is not plebian!) hackability trump all other concerns?

I think the fact that you call java not-compiled, but python interpreted shows your misunderstanding in this area. Both run exactly the same way, they are compiled into an intermediate bytecode which is run in a "VM". The normal Java VM has a JIT, the normal python VM does not, but pypy does and achieves performance on par with some of your compiled languages, at the cost of reduced c compatibility. I know C, Java, p…

Uh, I lumped in Java with the compiled languages?

And yeah, thats right there's like 80 million Python variants, some of which are compiled.

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

#295

Post by SippinLean »

Mahn wrote: post #6

Sounds like this can be fixed by moving away from animating opacity to something more rudimentary like flipping the display property in JS. CSS3 animations from my experience are a bit taxing in general, and something you want to use only in small bursts, not constantly running in the background.

That would, but right now the cursor fades in and out, it doesn't "blink" exactly, so this suggestion is not a 1:1 replacement.

Sounds like they need to optimize their CSS animations in general.

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

#296

Post by omegote »

> 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 honestly doubt the average javascripter could get his head around something like C++, specially for complex tasks like developing an editor.

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

#297

Post by watty »

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 how so many people have trouble understanding why things like VSCode or Atom are popular.

They're sexy, they are powerful (extensions for everything), portable, and extremely easy to extend thanks to Javascript being pervasive. I don't know for certain but I'd also assume writing an Electron app is easier than writing a similar app in a lower level language.

Is it really that hard to grasp? Performance has to be perceptible by the average person for it to affect user base. I prefer WebStorm but I've had absolutely no issues using VSCode on my laptop - which feels even faster than WebStorm.

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

#298

Post by watty »

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 how so many people have trouble understanding why things like VSCode or Atom are popular.

They're sexy, they are powerful (extensions for everything), portable, and extremely easy to extend thanks to Javascript being pervasive.

Is it really that hard to grasp? Performance has to be perceptible by the average person for it to affect user base. I prefer WebStorm but I've had absolutely no issues using VSCode on my laptop - which feels even faster than WebStorm.

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

#299

Post by lispm »

dahauns wrote: post #95
ue_ wrote: post #39

Earlier quoted context omitted.

Emacs is a little harder to write plugins for, but it runs natively and the only impediment is that more people know JS than they do elisp.

Lots of emacs functionality runs via its lisp VM. I'd hardly call that 'native'. I mean, Emacs had jokes about being bloated decades before Javascript (and Java, another contender for these jokes) even existed. :)

The jokes of GNU Emacs being bloated are from a time when machines with 8MB RAM were modern. The original NeXT computer was introduced in 1988 with 8MB RAM... The Mac II from 1987 started at 1MB, max at 8MB, ... today phones have 2GB RAM.

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

#300

Post by pcwalton »

coldtea wrote: post #162
cr0sh wrote: post #112

Earlier quoted context omitted.

You both do realize that similar arguments could have been made back in the day when moving from, say, command-line DOS applications to Windows API applications - right? Ultimately, computing has always been one of abstraction from the lower "layers". Taken far enough, one could spuriously argue that if you aren't soldering together the flip-flops that make up your logic and memory, you just aren't being efficient...

> You both do realize that similar arguments could have been made back in the day when moving from, say, command-line DOS applications to Windows API applications - right? No, we don't. With Windows API there's no sandbox and extra embedded language overhead (it's still native code like in DOS, and even optimized better, able to use more available memory than DOS would allow, etc.). Oh, and you also got the benefit o…

> Not to mention that the Windows API UI toolkit, while bad, is sane compared to the web stack.

Completely disagree. Charles Petzold's HELLO.C is hundreds of lines of code. Hello World on the Web is, well, "Hello world!".

"Sane" environments don't force you to make up a distinction between "long pointers" and "pointers" if you want to conform to the house style in order to match 16-bit x86 real mode. Or route all events through one WndProc, forcing use of "message crackers" to poorly recreate the ergonomics of addEventListener. Or have to recreate the vector graphics stack not once but twice in order to deal with the lack of forward thinking (GDI, GDI+, Direct2D). Or deal with incredible apartment threading complexity to maintain VB6 compatibility. Etc. etc.

If you had said .NET, maybe. But Petzold-style Win32 is bad.

Post reply on HN