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

761–770 of 801 posts

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

#761

Post by andreareina »

allenz wrote: post #520
bitwize wrote: post #469

An internet points out that Hackernews' favorite text editor takes up more CPU than the average Hackernews would have had at their disposal 20 years ago just to make the cursor blink on and off. Hackernews circles the wagons to justify the stupid engineering design decisions behind said editor based solely on the fact that embedding a complete Web browser just to draw buttons and text fields "won" over any sensible G…

I enjoyed your comment. The non-funny response is that all GUI layers suck, possibly because visual interfaces and abstract code are inherently incompatible. Since no one has managed to make the perfect GUI, we constantly look to improve on the tradeoffs we must make, which are different for different applications. 13% idle sounds egregious but higher battery usage isn't a problem for most if it excels in the areas t…

> higher battery usage isn't a problem for most if it excels in the areas that matter

As engineers it's our responsibility to not spend our users' resources unnecessarily. This thinking is how we got to the bloated web where pages need a megabyte (or several) of code just to render. Could you imagine an architect saying, "yeah, this design costs 2x that other one, but my clients are rich so it doesn't really matter"? The old saw that "anyone can build a bridge that stands up; it takes an engineer to build a bridge that barely stands up" applies.

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

#762

Post by [deleted] »

KirinDave wrote: post #752
allover wrote: post #704

Earlier quoted context omitted.

> Trying to shoehorn everything into "the web" 'Trying to shoehorn' is just your opinion. > Use the right tools for the job. What does that non-sequitur even mean in this context? Use a different native platform to write each native version of the app? That simply isn't viable for anything but very large companies. Or should I use Qt, with it's tiny support community? Also why is React/React-Native not 'the right too…

It's unfortunate that your opinion–that of the two most successful programmer's editors currently in use today are doing something right–is being heavily downvoted by people who object to the "web" invading on their territory for reasons unknowable. "Eating too many CPU cycles while idle" is a problem many, many text editors have faced. It's purely an unfair bias in this case that this is justification for trying to…

[deleted]

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

#763

Post by ballenf »

sedachv wrote: post #611
ballenf wrote: post #565

Earlier quoted context omitted.

What I'm suggesting is that, e.g., there are more Slack, Atom, VS Code, (and those are just Electron apps) etc. and/or those apps have more features because of the speed of development and iteration afforded by these inefficient abstraction layers. So, I can't give a specific example but am instead pointing at the diverse ecosystem of applications and rich functionality. It's logically impossible for me to prove that…

> It's logically impossible for me to prove that these apps wouldn't exist without inefficient abstraction layers. The literally millions of applications not written on top of the specific crapware you list are an existence proof. This was the case even with assembly/Pascal/BASIC applications on microcomputers in the 1980s. Your whole argument is that somehow the web stack is easier to write applications on top of be…

Very good questions that I can't answer. And it's not my 'bullshit rationalization' -- I'm not the one who decided to build all these products on this "crapware" stack. I'm just suggesting that this stack was chosen for some (hopefully) logical reason.

If speed of development isn't the reason, then what is the attraction? I'm serious and curious. I looked through your profile and you clearly know your shit. Are we just in a period of a bad stack being popular and used despite there being other, better options?

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

#764

Post by [deleted] »

KirinDave wrote: post #748
abiox wrote: post #609

Earlier quoted context omitted.

> Use the right tools for the job i wonder if this expression constitutes a thought-terminating cliché.

It does, inasmuch as objective metrics for "correctness" don't exist in our field. The best we can do is show "incorrectness." It's absurd to say, "My tool is correct and therefore should be used," when all we really can demonstrate is, "My tool lacks these specific deficiencies I can identify in another choice." This bug comes nowhere near demonstrating that Electron or VS Code or Atom are built incorrectly or incor…

[deleted]

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

#765

Post by jblow »

trishume wrote: post #631
jblow wrote: post #502

Earlier quoted context omitted.

Ehh, game engines are not really retained-mode in the way you mean. There isn't usually a cordoned-off piece of state that represents visuals only. Rather, much of that state is produced each frame from the mixture of state that serves all purposes (collision detection, game event logic, etc). "What happens if you try to present an immediate mode API for UIs is the status quo with APIs like Skia-GL." I don't know wha…

This argument looks like you and pcwalton are arguing about different definitions of "immediate mode API". I think both of you agree with each other on object-level propositions. pcwalton seems to be presuming that part of the contract of an "immediate mode API" is like old-school ones it actually immediately draws to the frame buffer by the end of the call. Whereas you are talking about modern "immediate mode API"s…

"so you need some data structure that sticks around between frames specific to the widget type, so that's what retained mode APIs like Qt do for their widgets."

Immediate mode GUI systems are allowed to keep state around between frames and the most-featureful ones do. The "immediate mode" is just about the API between the library and the user, not about what the library is allowed to do behind the scenes. The argument that retained-mode systems are inherently better at this doesn't hold water; it is kind of an orthogonal issue.

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

#766

Post by jblow »

swah wrote: post #621
jblow wrote: post #561

Earlier quoted context omitted.

It is a little confusing because we are talking about both rendering and GUIs, but ... "retained mode" in this case refers to the GUI itself, not the method of drawing. Motif and Xlib are "retained mode" in the GUI sense because if you want there to be a button, you instantiate that button and register it with the library, and then if you want it to become visible or invisible or change color you call procedures that…

But can you imagine something like Word being written without the "retained-mode" abstraction?

Yes, absolutely, and in fact I think it would be a much better program.

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

#767

Post by jblow »

c-smile wrote: post #645
jblow wrote: post #521

Earlier quoted context omitted.

I am assuming that your caret bar may be overlapping text in some way, or that there is a background bitmap that you might be alpha-blending against, etc. Basically I don't want to make an assumption that might break if the UI gets nicer. The case of a strictly opaque strictly rectangular non-antialiased non-smoothly-moving bar does not seem very interesting or nice-looking.

Are you speaking about some particular implementation of this all just from your imagination?

You are talking to someone who has done 3D rendering professionally for 21 years. What's your background?

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

#768

Post by allenz »

TeMPOraL wrote: post #716
allenz wrote: post #629

Earlier quoted context omitted.

What do you find stupid? The way I see it, HTML/JS is a pretty good higher-level GUI language, and much effort has been spent making it work well. The overhead is worth it if it makes developers more productive.

Is it? The costs which you offset with developer productivity get multiplied times the number of users , which is orders of magnitude more than number of developers.

And value delivered also gets multiplied by the number of users. VS Code users decided that they like it even after accounting for Electron. Clearly, then, VS Code has certain strengths, and I'd argue that some of those strengths are made possible by Electron. Second, great design requires experimentation, and Electron makes it easier to experiment with editor UI. VS Code could become a place to prototype ideas that eventually improve your more efficient editor.

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

#769

Post by allenz »

elsurudo wrote: post #706
allenz wrote: post #629

Earlier quoted context omitted.

What do you find stupid? The way I see it, HTML/JS is a pretty good higher-level GUI language, and much effort has been spent making it work well. The overhead is worth it if it makes developers more productive.

Fair enough, but double-digit usage of an entire core... when the program is IDLE? how can you justify that? That's just broken.

They will indeed fix this. At minimum, they can freeze the editor when it's out of focus. So there is no need to justify--this is a minor oversight, as someone phrased it over at Slashdot.[1]

I was responding to those who believe that this demonstrates a fundamental flaw in using Electron. My response emphasizes the tradeoffs involved. If they couldn't fix it, 13% background is undesirable, but it's not a dealbreaker for me if there are redeeming qualities. And it seems that VS Code certainly has some redeeming qualities.

[1] https://developers.slashdot.org/comments.pl?sid=10406465&cid...

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

#770

Post by allover »

KirinDave wrote: post #752
allover wrote: post #704

Earlier quoted context omitted.

> Trying to shoehorn everything into "the web" 'Trying to shoehorn' is just your opinion. > Use the right tools for the job. What does that non-sequitur even mean in this context? Use a different native platform to write each native version of the app? That simply isn't viable for anything but very large companies. Or should I use Qt, with it's tiny support community? Also why is React/React-Native not 'the right too…

It's unfortunate that your opinion–that of the two most successful programmer's editors currently in use today are doing something right–is being heavily downvoted by people who object to the "web" invading on their territory for reasons unknowable. "Eating too many CPU cycles while idle" is a problem many, many text editors have faced. It's purely an unfair bias in this case that this is justification for trying to…

Yes it is sad that it is one of those topics that HN users seem incapable of discussing objectively. Meanwhile Electron usage grows and grows, and will continue to until someone comes up with a viable alternative.
Post reply on HN