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

551–560 of 801 posts

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

#551

Post by sedachv »

ballenf wrote: post #181
TeMPOraL wrote: post #155

Earlier quoted context omitted.

That's totally unfair. You should compare it to startup time of Word from, I don't know, 10 - 20 years ago. Around the same time (if not less), and Google Docs still can't match the features of old Words. The point being, for the past decade or two, we've been burning all hardware performance improvements on things that are neither visible to user, nor enable them to do more with their computer. Surely, there must be…

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 "abstraction layers" is insulting to all of the programmers working on Free Software libraries, compilers, runtimes and operating systems.

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

#552

Post by allover »

problems wrote: post #531
KirinDave wrote: post #492

Earlier quoted context omitted.

I'm glad at least we made fun of both sides. I really wish there was a good option for GUI toolkits. Nearly all are either too primitive to make more than freshmen college (or tenured physics professor) level work or asymptotically approach web browsers without all that tedious attention to improvement and accessibility.

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.

If you learn React, you can write for web, multi-platform desktop and (native) mobile, with React Native. Same can't be said for Qt or WPF.

Also the Qt community is minute compared to the JS community, that is significant.

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

#553

Post by fetbaffe »

efdee wrote: post #304
thomastjeffery wrote: post #243

Earlier quoted context omitted.

> it's the best we have (if you're looking for a cross platform solution, anyway) No it's not. If you want a fast full-featured cross-platform GUI toolkit, there are many: GTK+ and Qt are especially great, and have bindings for several languages.

I can't speak for Qt, but GTK+ is not that great outside of the Linux bubble. IMHO, of course.

Qt is not that fun either, at least two years ago. Old style class hierarchies, clunky abstractions and awful build step (QMAKE). It got better with the use of lambdas, no longer necessary to have class to connect to a signal, lambda works as well.

However QML is an improvement. It was a bit quirky to get render the way you wanted and it was not native & look and feel, but maybe have gotten better since I used it. I could imagine that TypeScript + QML could be quite pleasant. Big downside is that the install size of your program is quite big.

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

#554

Post by tetromino_ »

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…

If by "responsive, fast, reliable" you mean awful screen tearing when you mix X11, OpenGL, and/or video playback. Fixing it on any given machine is often possible through some voodoo and a hand-rolled combination of driver and software settings, but that voodoo works only for one specific combination of hardware and driver version, and every update means more rounds of trial and error...

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

#555

Post by ldev »

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…

> 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 both parts of window will have full vsync - insane, huh? :)

It's scary how good Windows is.

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

#556

Post by klibertp »

gmfawcett wrote: post #325
lispm wrote: post #307

Earlier quoted context omitted.

GNU Emacs Lisp code is certainly not native - not until a JIT will be widespread. GNU Emacs usually compiles Lisp code to a byte code which is interpreted by a byte code engine written in C. If you use a Common Lisp based editor like Clozure CL, Allegro CL and LispWorks have, they don't use a C-based byte code interpreted. The Lisp code is compiled directly to native code. Which makes editor extensions running in nat…

I should be more clear. I don't think that just because Emacs contains an Elisp interpreter, we should call it a "non-native" application -- even if Elisp is integral to Emacs' operation. If forced, I would say that Emacs-the-platform is native, and Emacs the system of Editor MACroS is not, since the macros run on the Emacs platform. But it seems kind of pedantic.

> I don't think that just because Emacs contains an Elisp interpreter,

The number of lines of Elisp my Emacs uses (counting plugins, but also built-ins) is actually more than twice the number of lines of C.

It's not that "Emacs contains an interpreter", rather it's "Emacs has all these features written in Elisp [...a looong list here...] Oh, and it also has an interpreter to execute it all".

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

#557

Post by [deleted] »

Mister_Snuggles wrote: post #435
paulirish wrote: post #244

Earlier quoted context omitted.

Powerful* text editors built on the web stack cannot rely on the OS text caret and have to provide their own. In this case, VSCode is probably using the most reasonable approach to blinking a cursor: a `step` timing-function with a CSS keyframe animation. This tells the browser to only change the opacity every 500ms. Meanwhile, Chrome hasn't yet optimised this completely yet, hence http://crbug.com/361587 . So curren…

> Powerful* text editors built on the web stack cannot rely on the OS text caret and have to provide their own. Is there any reason that Electron couldn't provide an API that would expose the system caret in an OS-agnostic manner? Windows, for example, has an API[0] that can arbitrarily show the caret at a given point in the window. Sounds like something that would be useful to many apps and not get in the way for th…

[deleted]

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

#558

Post by simplyinfinity »

allover wrote: post #552
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.

If you learn React, you can write for web, multi-platform desktop and (native) mobile, with React Native. Same can't be said for Qt or WPF. Also the Qt community is minute compared to the JS community, that is significant.

js community is filled with 20-somethings with ADHD (i'm 26) that reinvent the wheel every 2 weeks instead of helping polish other projects.

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

#559

Post by stock_toaster »

allover wrote: post #552
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.

If you learn React, you can write for web, multi-platform desktop and (native) mobile, with React Native. Same can't be said for Qt or WPF. Also the Qt community is minute compared to the JS community, that is significant.

"If you learn how to build doghouses, you can build skyscrapers, bridges, and nuclear power plants."

Use the right tools for the job. Trying to shoehorn everything into "the web" makes everything just as shitty as the web.

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

#560

Post by FridgeSeal »

always_good wrote: post #262
kitsunesoba wrote: post #217

Earlier quoted context omitted.

Just because it's the best we have (if you're looking for a cross platform solution, anyway) doesn't mean that we've reached the peak and can just quit. We can do a hell of a lot better, and doing anything less is tragically underselling ourselves. There are no laws of physics preventing a better solution from existing. No, creating something better isn't easy, but neither have any of the other technological breakthr…

"Quitting" is not how I'd describe Atom and VS Code. You might not like the envelope they are pushing, but they are cutting-edge explorations into web tech, coinciding with other cutting-edge developments like HTML/JS -> Native interfaces.

Are they really cutting edge? Or are they just an excuse to cram more javascript and web tech into unrelated areas.

Just because js is good on web, doesn't - and shouldn't - mean that we should be doing that.

Post reply on HN