Live data from Hacker News

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

github.com

511–520 of 801 posts

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

#511
post #63

Earlier quoted context omitted.

> easy to get started Yes. > cross platform support Yes. > Because you can write plugins in JS? Yes. --- As much as I prefer native programs as a user, it's impossible to ignore the benefits of cross-platform development and plebeian hackability/debuggability.

>> cross platform support > Yes. WOW FINALLY SOMETHING that will run on my LINUX and FreeBSD! ohh.. a lot of plugins don't support linux and it doesn't build on BSD?

Define a lot. Every plugin I use on Atom run on Linux fine.

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

#512

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?

Please don't.

https://news.ycombinator.com/newsguidelines.html

https://news.ycombinator.com/newswelcome.html

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

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

#513
post #412
post #382

Earlier quoted context omitted.

> Going to windowing GUIs from character-mode DOS was a massive usability improvement. No more exotic ctl-alt-function key combos cough Blender ...

Unfortunately - the OSS world has a shortage of good UX people, and the engineers tend to be the ones steering the ship. I would point to Eclipse as another classic example of "obviously designed by an engineer". There's tons of functionality under the hood and it's a fantastic jumping-off point for further customization... but its layout is intensely non-intuitive in so many ways compared to a purpose-built IDE. Eve…

GIMP is pretty easy to pick up if you've used desktop apps before. It follows the sort of conventions you'd expect.. Blender, on the other hand, has a very unique approach to UX.

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

#514

Earlier quoted context omitted.

> By making a text editor out of web technologies, you can reuse all the web ecosystem the web has, and enjoy also its customizability. For instance I wanted to be able to display PDFs directly in VSCode. I went to look for a plugin, and there was one You know where else you could do the exact same thing AND have a 10x faster and 10x more memory/battery efficient editor? If a native editor just gave you a webview tha…

> 10x faster and 10x more memory/battery efficient editor? Except for the startup time --- with which I can live with --- I never felt a difference in speed between native text editors ans VSCode. There is one, but I don't notice it. Human are much more slower than computers, so as long as it is not taking more time that I need to notice it, I don't care. Nowadays my computer has enough memory so I can afford to not…

>Except for the startup time --- with which I can live with --- I never felt a difference in speed between native text editors and VSCode. There is one, but I don't notice

Try editing anything larger than a simple program file (from a large JSON to a CSV as devs often do) and you'll do. Try hex editing a large binary. And many other tasks.

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

#515
post #305

Earlier quoted context omitted.

Do you want to listen to the reasons, or just tell them to "go make your own if you don't like it"? You can't have it both ways. I agree that simply saying X sucks is not a valid argument. Howeever with CSS/HTML the flaws are too numerous and already discussed ad nauseam over the past 15 years. Everytime a new version of CSS comes out, people go and try it and find out that it sucks, whether its th broken box model o…

> Which also explains why there isn't even a reference implementation. As someone who has spent years implementing those standards, a reference implementation would not help me at all. > As far as UI layout is concerned I am fairly sure I could out-compete a web developer in terms of time taken to implement, using something like IMGUI. Dear imgui's layout model doesn't scale at all, due to the fact that it's immediat…

>a reference implementation would not help me at all.

Well, considering that the web has been for decades a landmine of subtle rendering differences based on different interpretations of the same standards, it would surely help others...

Also, I'm not sure what you're saying here. That, warts and all, you love the web as a programming platform?

Well, maybe you do.

But then again, you don't program everyday IN it. You program a rendering engine for it in Rust, so you're safely protected from the horrors of web programming.

>Dear imgui's layout model doesn't scale at all, due to the fact that it's immediate mode. It redoes layout from scratch every frame.

Aren't (or at least weren't) most computer games "immediate mode" too, and far more demanding than any web page?

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

#516

Earlier quoted context omitted.

bummer n-gate didn't comment on its own hn post

I was really looking forward to that write up, as well. Unfortunately, the author must have some rule about not breaking the fourth wall. Or they avoid softballed summaries?

I think a recursive n-gate situation would be delightful. Someone should make this happen.

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

#517

Earlier quoted context omitted.

If you could n-gate every article as it's posted, that would be awesome.

For those who missed it, n-gate satirizes some HN posts, to the delight of all: http://n-gate.com/hackernews/

Oh my god... n-gate is pure gold!

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

#518

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…

You're projecting quite a bit there. There's tons of comments lambasting what's going on in the article.

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

#519

Earlier quoted context omitted.

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.

that was a typo. "not-interpreted" was my intended statement. And I'd love for you to show me a python variant that is compiled in the same way that C is compiled. The closest is nuitka, which...isn't.

cpython? I know the regular python-2.7 installer in debian does binary compilation, producing little *.pyc files for everything

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

#520

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 that matter: responsiveness, design, power, completeness. In contrast, Wayland improves not just idle, but also overall performance, which is the main consideration for a low level API.
Post reply on HN