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

561–570 of 801 posts

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

#561

Post by jblow »

rleigh wrote: post #537
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…

Motif and Xlib use expose events to handle drawing. Doesn't imply retained mode drawing; you could use either in the handler.

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 poke values on that instantiated button. In IMGUI you don't preinstantiate; you just say "draw a button now" and if you don't want it to be visible, you just don't draw it, etc.

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

#562

Post by corford »

Hilarious. I can reproduce on my Dell Inspiron 15 5000 (core i7 running Windows 10) but it's not as pronounced as in the bug report. CPU usage bounces between 0.5% and 2.5% (which is obviously still ridiculous).

I almost want to swap back to using sublime out of protest but vscode's tighter git integration/workflow is hard to give up :(

Edit: I've always wondered why vscode couldn't be written in portable C/C++/Rust/D and then embed a V8 engine to power a javascript plugin API (a bit like sublime does with python)?

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

#563

Post by smitherfield »

usrusr wrote: post #500
smitherfield wrote: post #381

Earlier quoted context omitted.

On a related note, it seems crazy to me that for actively maintained, cross-platform, native widget GUI libraries, your options are… Qt. (Not that Qt is a bad library, but it's bizarre that such an important area is so neglected by our industry).

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 dialogue:

---

Socrates: What is the most popular programming language?

Developer: Java.

Socrates: And why is Java so popular?

Developer: It's the first language most people learn nowadays, so everyone knows it.

Socrates: So it's popular because it's popular?

Developer: Well, it's very similar to C++, which was the most popular language when it first came out, so it was easy for people who already knew C++ to learn.

Socrates: So why not keep using C++?

Developer: C++ had a lot of problems that made it hard to use, and Java solved a lot of those.

Socrates: Such as?

Developer: If you wrote an application in C++ that ran on any given operating system, like Windows, you wouldn't be able to run the same code on another operating system like Linux or Mac; you would have to rewrite much of your work from scratch to support more than one operating system. Java is "write once, run anywhere." Your Java program will run exactly the same way, without having to rewrite anything, on any operating system that has a Java implementation.

Socrates: Interesting! Can you show me?

Developer: (Writes "hello world," demonstrates it runs the same in both cmd.exe and Bash)

Socrates: And that works with real programs too?

Developer: What do you mean? This isn't a very long or useful program, but it is an real program.

Socrates: What's special about what you just showed me? Can't you write these command line things in any language? Look: I learned a bit of Python a few years ago. (enters python -c "print 'Hello, world!'" in both terminals)

Developer: OK, maybe that wasn't the best example, but when you're doing more complicated stuff it gets harder and harder to write code for more than one operating system in a language like C++, so a language that runs the same everywhere, like Java, or Python, is better to have.

Socrates: So like an application that you would install?

Developer: Exactly!

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.

Socrates: Hm?

Developer: You can't do that in Java.

Socrates: So, Java is the most popular programming language, but you can't use the programs you write in it?

Developer: Alright, you got me there. Usually Java is used for writing applications that run on servers, not PCs.

Socrates: Servers?

Developer: Yeah, like if you go to a website, there might be an application on its server to fetch your account information from a database.

Socrates: But why do you need a special application for that? Can't you just ask for the information you need directly?

Developer: Good question. We're moving in that direction. But for some things you really do need some kind of custom logic, and for those things Java is a good solution across different platforms.

Socrates: What different platforms are there in servers?

Developer: There aren't really that many platforms. Almost all servers run Linux. But there's also a few that run Windows, or FreeBSD, which is very similar to Linux.

Socrates: So if you were on a less popular operating system, like Windows, you would use Java to be compatible with Linux?

Developer: Probably not; really, the only reason you would use Windows on a server instead of Linux is if your application were written in C#, which is Microsoft's Java competitor.

Socrates: So Java is the most popular-because-it's-popular programming language you can't write programs in, and it's useful because it runs on every platform, on only one platform?

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

#564

Post by Mister_Snuggles »

Someone wrote: post #547
Mister_Snuggles wrote: post #481

Earlier quoted context omitted.

My point is that the built-in text edit control needs some way to draw it's caret, so surely a universal method to draw a blinking caret exists somewhere.

I'm not aware of any system where one can create that caret without a text edit control to hold it. That means that, if the standard text edit control isn't suited for what you want to do, you can't have the caret. Certainly, on the original Mac OS (a system on which I worked on OS patches for detecting the location of the caret) the method that application used for drawing the caret varied widely. I've seen it imple…

> I'm not aware of any system where one can create that caret without a text edit control to hold it.

Windows allows this. In a parent comment I posted a link to the API docs. All Windows requires is a window to hold the caret, it doesn't care what kind of window it is.

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

#565

Post by ballenf »

sedachv wrote: post #551
ballenf wrote: post #181

Earlier quoted context omitted.

On a per-application basis, you are probably correct. 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, then that is directly immediately beneficial to the end user. Not to mention faster design iteration, implementation of new features etc.

> 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 these apps wouldn't exist without inefficient abstraction layers. It's my supposition, and the developers who write electron apps would probably agree.

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

#566

Post by insulanus »

ldev wrote: post #555
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…

> X11 runs really well these days -- responsive, fast, reliable Well, you haven't seen Windows then - the graphics stack is phenomenal and a marvel of engineering. nVidia drivers crash? I only get a second of black screen and then resume my work. Yep, that's right - no other GUI program crashed, I didn't had to do anything, literally just 1 second of black screen. Oh and you can have one window on two monitors and bo…

Yes, and it only took 30 years, too!

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

#567

Post by charrondev »

ldev wrote: post #555
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…

> X11 runs really well these days -- responsive, fast, reliable Well, you haven't seen Windows then - the graphics stack is phenomenal and a marvel of engineering. nVidia drivers crash? I only get a second of black screen and then resume my work. Yep, that's right - no other GUI program crashed, I didn't had to do anything, literally just 1 second of black screen. Oh and you can have one window on two monitors and bo…

I don't much about graphic stacks, but in my experience the best, as least from the perspective of someone using multiple HiDPI displays macOS is far and away the best. Many windows applications don't scale properly or if they do they require special settings to do so. If you have monitors with different levels of scaling your going to have a terrible time on windows.

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

#568

Post by klibertp »

DigitalJack wrote: post #98
trimbo wrote: post #80

Earlier quoted context omitted.

This might mark the first time in history that Emacs was trotted out as an example of a performant editor. I say this as an Emacs user.

Emacs takes 8-15 seconds to open on my new i7. That matters when I just want to do quick edits. Vscode takes 3.

It's not "Emacs" itself, it's plugins and Elisp libraries you have loaded. Emacs itself - the GUI, even including (optionally) blinking cursor - is actually quite fast.

To prove this, this command:

    time emacs -Q --eval "(kill-emacs)"
reports ~0.2 sec on my system.

My normal Emacs, just as yours, needs ~12 seconds to start up. But I made it this way by explicitly enabling and requiring things. I could, with some effort, get the time down to 5-8 seconds (byte-compilation and gathering autoloads in one place), and even back to around a second if I was desperate enough to try dumping the image of a running Emacs to disk (I did it once and succeeded, although the process wasn't pretty). I don't do this because I don't care that much, but the option is there.

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

#569

Post by bitwize »

zbuf wrote: post #534
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…

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…

It's the GNOME style of development: as soon as a bug appears which takes effort to fix, mark it EWONTFIX, declare it to be a symptom of the inherent brokenness of the current stack, then burn the whole thing to the ground and start over. Don't even let that which was burned fertilize new growth; it is tainted and must be purged entirely.

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

#570

Post by JdeBP »

Touche wrote: post #163
Philipp__ wrote: post #50

Earlier quoted context omitted.

Are you kidding me? Look at the raw performances and benchmarks of Vim/Sublime/Emacs, compare it to VSCode and Atom and you will see. If you don't believe the numbers then use both side by side, open 250MB file in all of them and look at the screen. And I still see native editors used more (for example latest StackOverflow survey, showed that Notepad++, Vim and Sublime combined are used much much more than VScode and…

I don't know what you are arguing about, I didn't say Electron apps are as performant as C++ written editors. I said that users, as evidenced by their downloads, don't find this to be as big of a concern as you (and many other HN commenters) do.

And xe said in turn, which you completely overlooked, that at least one survey didn't bear out your claim about usage at all. Rather than ignore that inconvenient point, you could have countered with what data you actually have on text editor downloads.

You also appear to be falling into the developers are not users trap.

Post reply on HN