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

731–740 of 801 posts

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

#731

Post by dahauns »

pantulis wrote: post #272
gmfawcett wrote: post #165

Earlier quoted context omitted.

Most of those jokes are completely out of date. "Eight Megs and Constantly Swapping" used to be a big deal, but today it's not. I don't think running Elisp in Emacs takes away from it being "native." At least insofar as there are no popular text editors (that I know of!) which expect you to compile your plugins and macros to native code. They all have interpreters of one kind or another. What Emacs doesn't have, thou…

Which begs the nice corollary: the definition of "native" doesn't happen to be fixed and changes with time.

Case in point: https://news.ycombinator.com/item?id=13944757

:)

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

#732

Post by mvindahl »

psyc wrote: post #622
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 mean, I couldn't agree with you more about the asininity of embedding a browser in a 'native' app (for anything other than web browsing). But I use VSCode all day, every day, and subjectively it feels zero-latency on my aging laptop.

It's kind of a crazy concept, especially if you are old enough to remember the days where RAM was counted in kilobytes and you would optimize assembler code to save clockcycles.

On the other hand, this is 2017, and people apparently don't care much about the footprint of their software, as long as it's convenient and it solves their problem. And ultimately that's what counts I guess.

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

#733

Post by mvindahl »

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…

VSCode runs nicely on my MacBook. It doesn't feel like a web application to me, in the same way that IntelliJ IDEA doesn't feel like it's written in Java. I'm sure that both VSCode and IDEA could run even faster if they were ported to, say, C, but in both cases that would be a large investment for improvements that I wouldn't even detect.

So I guess it makes sense to optimize for maintainability i this case, i.e. not having one codebase per native OS.

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

#734

Post by norswap »

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…

Yes, embedding a web browser is wasteful.

But, it is EXTREMELY EASY. There's a reason why Github, Microsoft, Facebook, Adobe etc converged on this decision, and it's not the bandwagon effect. Faced with the same task recently, I did my research, and it is indeed easy.

Since I work on the JVM, my alternative was JavaFX. That didn't seem so bad, but it was much more work. If you look at say IntelliJ IDEA on some platforms, you'll see the text rendering is much uglier than on Atom. Regrettably, if you want to acquire users, that matters more than conservation of resources.

I'm curious: have you ever tried interfacing with X11?

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

#735

Post by tinus_hn »

coldtea wrote: post #476
tinus_hn wrote: post #52

Earlier quoted context omitted.

iTunes has the same issue with its spinner while syncing, it takes about 20% CPU time.

Who said it's the spinner in that case? After all, it IS syncing at that time, which means it does a lot of stuff. Whereas the issue here is with the caret shown when the editor is idle.

Activity Monitor allows you to easily profile what the application is spending its CPU time on and it shows that iTunes spends an excessive amount of its time on updating the UI, specifically the spinner.

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

#736

Post by rleigh »

jblow wrote: post #561
rleigh wrote: post #537

Earlier quoted context omitted.

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…

This is a fair point. All the mapped XWindows are certainly "retained" from this point of view.

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

#737

Post by yoklov »

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…

Windows' stack is still a ways from being reliable in a lot of somewhat important cases like (real) fullscreen, but it's certainly miles beyond X11 and Linux.

(I don't have enough experience with Mac's to speak to it).

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

#738

Post by yoklov »

reitanqild wrote: post #593
aerique wrote: post #443

Earlier quoted context omitted.

I think it's because Namco had a patent on games in loading screens from 1995 to 2015: http://kotaku.com/the-patent-on-loading-screen-mini-games-is...

Ghostbusters game on c64 had it when I bought it used in 1991 or 92 I think.

It's a common example for a patent that had a lot of prior art but was granted anyway.

I don't know enough about patents to say if there was a reason the prior art didn't apply, but I know that Namco was fairly protective of it and it was somewhat limiting for people working in the game industry.

Although, loading screens are less common now than they were back then, and I think that would still be case even if such a thing were never patented.

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

#739

Post by brilliantcode »

brilliantcode wrote: post #463
dragonwriter wrote: post #328

Earlier quoted context omitted.

> Swing was at least meant to do UI. Web stack is not; The ancient history of the web, clearly, is different, but the modern web stack, both in terms of specs (WHATWG HTML/W3C HTML5 and related standards) and modern browsers are very much engineered for applications, not just classic documents, as a primary use case.

In the minds of people who've spent long time on traditional client-server tier architectures view Javascript as a toy and view all the Javascript frameworks as "over engineering". Yet, what they fail to realize is they are comparing a webpage to an application. An application contains information about the state it's in. Handling the application state has always remained complex and it has been two way coupling to t…

Why was this downvoted? I expect a rebuttal instead just silent downvotes. This just solidifies my opinion, there are lot of dinosaurs on HN and they are going to find themselves unemployable without Javascript in the future.

Javascript is essential knowledge, along with AWS. Software engineering has changed in the past 20 years like it or not.

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

#740

Post by nikanj »

boterock wrote: post #643
charrondev wrote: post #567

Earlier quoted context omitted.

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.

On the other hand, connecting a 4k display in windows will default to configure it at 200% scaling, in mac it defaults to render everything tiny as ants.

I have a 43" 4k screen. It's near impossible to make Windows NOT use scaling, even if you disable it everywhere, the next Windows updates usually reset your carefully created registry hacks.

I wish Windows based scaling on DPI instead of resolution, the system seems to be aware of both. On a more general level, I wish there was any hope of passing feedback to Microsoft/Apple/etc.

Post reply on HN