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

611–620 of 801 posts

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

#611

Post by sedachv »

ballenf wrote: post #565
sedachv wrote: post #551

Earlier quoted context omitted.

> But if the additionally abstraction layers allow there to be greater diversity of applications and more tools for more niche cases because development is easier and/or faster Please try to find a single example where this is true. Niche cases and greater diversity all come from a lot of work keeping runtimes up to date and APIs backward-compatible. This is only because of Free Software. Trying to credit this to "ab…

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 because . To go back to the Pascal example, a lot of people who program in Delphi strongly disagree even today, and Delphi has been around since 1995. What makes you think that the web stack has a higher speed of development than other software tools? Why do you think that high-speed development depends on inefficient abstractions? That is all total nonsense. There are a lot of problems with the web stack. You need to stop making up bullshit rationalizations and learn about other approaches to software development.

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

#612

Post by chetanahuja »

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…

"3% idle sounds egregious but higher battery usage isn't a problem for most"

Oh God this is why we can't have nice things. How the heck is someone actually justifying this stupid shit here?

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

#613

Post by jodrellblank »

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…

https://pavelfatin.com/images/typing/editor-latency-windows-...

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

#614

Post by flukus »

BHSPitMonkey wrote: post #600
flukus wrote: post #595

Earlier quoted context omitted.

I think that's a case of necessity being the mother of invention. IME the windows 10 drivers crash much more frequently than the linux or windows 7 ones ever did.

I don't think it's fair to blame the OS for driver crashes. Those are a result of third parties and can happen on any platform.

That varies on the OS/driver/hardware, but IMO, the new AMD graphics drivers being in the kernel tree are the way to go, or something similar like a partnership between MS/AMD/Nvidia.

As a consumer it's incredibly frustrating to have a buggy driver and not know who is responsible. Is it MS? Windows comes with a lot of drivers so blaming MS seems fair. Is it the hardware manufacturer? Sometimes you can get the latest drivers but the OEM hardware isn't quite standard so you're screwed. Is the OEM to blame? Usually, because they have their own driver update system, but then the question is why can't they use the native windows update system?

The current situation on windows seems to be that no one is responsible.

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

#615

Post by theoh »

audidude wrote: post #575
zbuf wrote: post #534

Earlier quoted context omitted.

Best bit is that X11 runs really well these days -- responsive, fast, reliable. Emacs runs great, gitk, xterm, xosview, mplayer window manager, even Firefox is alright. Renoise, Maya, Blender too. Not to mention network transparency when I need it. It's a great environment to get my work done, and 3x hi res displays is the stuff I dreamt of 15 years ago. So it's a good job we're about to throw it all out and start ag…

> Not to mention network transparency when I need it You realize that no X client draws like this nor has for 20 years right? They all use xshm to upload pixels so this "network transparency" is just buffer copying over the network. Not entirely different from a texture upload to a GPU. > So it's a good job we're about to throw it all out and start again, eh folks? Yes, by those of us who have been working on the sam…

In 2000, I don't think many open source X clients (typically Linux stuff) used xshm. Not using X any more, I can't really comment on the current scene. But apart from things like MAME and vlc, what app needs it? And web browsers, of course.

(Accelerating OpenGL in hardware but displaying in an X11 window is a different question.)

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

#616

Post by rpeden »

skc wrote: post #579
problems wrote: post #531

Earlier quoted context omitted.

Qt pretty much nails this balance, WPF isn't bad either. Both will run circles around browsers at rendering performance and are much less tedious to develop in unless you've only done web dev before.

Such a pity that WPF was never ported to other platforms That's a UI framework that was done right in my opinion. Fast, incredibly flexible and sane. That it's been relegated to boring internal only enterprise app development is pretty sad. I enjoyed working with it immensely.

Avalonia is a decently nice cross platform C# + XAML GUI toolkit. It doesn't cover every use case WPF does, of course, but I've still found it pleasant to use.

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

#617

Post by audidude »

zbuf wrote: post #608
audidude wrote: post #575

Earlier quoted context omitted.

> Not to mention network transparency when I need it You realize that no X client draws like this nor has for 20 years right? They all use xshm to upload pixels so this "network transparency" is just buffer copying over the network. Not entirely different from a texture upload to a GPU. > So it's a good job we're about to throw it all out and start again, eh folks? Yes, by those of us who have been working on the sam…

> You realize that no X client draws like this nor has for 20 years right? They all use xshm to upload pixels [...] You seem to be misinformed. Of the applications I mentioned, the main ones (gitk, xterm, emacs, xosview) are not doing that; seen clearly by analysing the X traffic. Of course, some of these could be built with an optional Qt front-end, in which case I would not be surprised. So you stated clearly "all"…

That's precisely why I stated 20 years. Those programs were written before that and largely haven't changed since.

If you wan't anti-aliasing in any of those above (gitk/emacs come to mind) you'll be doing client side rendering of fonts and copying pixels.

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

#618

Post by monochromatic »

audidude wrote: post #617
zbuf wrote: post #608

Earlier quoted context omitted.

> You realize that no X client draws like this nor has for 20 years right? They all use xshm to upload pixels [...] You seem to be misinformed. Of the applications I mentioned, the main ones (gitk, xterm, emacs, xosview) are not doing that; seen clearly by analysing the X traffic. Of course, some of these could be built with an optional Qt front-end, in which case I would not be surprised. So you stated clearly "all"…

That's precisely why I stated 20 years. Those programs were written before that and largely haven't changed since. If you wan't anti-aliasing in any of those above (gitk/emacs come to mind) you'll be doing client side rendering of fonts and copying pixels.

> no X client draws like this nor has for 20 years

If something was written a long time ago and hasn't changed in this respect, BUT is still widely used... you can't say that "no X client draws like this nor has for 20 years."

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

#619

Post by abiox »

smitherfield wrote: post #563
usrusr wrote: post #500

Earlier quoted context omitted.

An interesting observation. But isn't the explanation rather obvious? Writing desktop applications to sell for money, that has quietly disappeared. It still exists, somewhere, but so does horseshoe-fitting (the few experts are probably making decent money, but it's a zombie business nonetheless). Between a few established offerings that won't be looking for a new framework any time soon, desktop-packaged web and all…

Yes, I know why it's the case nowadays: at my work, for example, I occasionally touch all the major areas of modern software development — server backends, mobile, Javascript-in-the-browser and meta-software for writing software — but I've never done what the average person, and maybe even I, would think of when they hear the term "software development." And it does seem very very strange. I'm imagining this Socratic…

>Socrates: OK! So could you show me a real application then? Like, it says "Hello, world!" in a window, with a menu and buttons and stuff? And it will be the same on both Windows and Linux? >Developer: No, that's not possible.

swing? awt? javafx?

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

#620

Post by jamesgeck0 »

flukus wrote: post #614
BHSPitMonkey wrote: post #600

Earlier quoted context omitted.

I don't think it's fair to blame the OS for driver crashes. Those are a result of third parties and can happen on any platform.

That varies on the OS/driver/hardware, but IMO, the new AMD graphics drivers being in the kernel tree are the way to go, or something similar like a partnership between MS/AMD/Nvidia. As a consumer it's incredibly frustrating to have a buggy driver and not know who is responsible. Is it MS? Windows comes with a lot of drivers so blaming MS seems fair. Is it the hardware manufacturer? Sometimes you can get the latest…

You're making this harder than it needs to be. All Windows drivers are signed. Blame the party that signed the buggy driver.
Post reply on HN