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

161–170 of 801 posts

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

#161

Post by [deleted] »

dheera wrote: post #40
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…

Yep. I also can't wrap my head around the fact that we are now constructing buttons, drop-down boxes, tagged text boxes using dozens of nested layers instead of a native widget that writes directly to the screen. My 486 rendered UIs with nearly imperceptible lag. Google Docs takes a good 2-3 seconds to spin up a UI on my i7.

[deleted]

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

#162

Post by coldtea »

cr0sh wrote: post #112
dheera wrote: post #40

Earlier quoted context omitted.

Yep. I also can't wrap my head around the fact that we are now constructing buttons, drop-down boxes, tagged text boxes using dozens of nested layers instead of a native widget that writes directly to the screen. My 486 rendered UIs with nearly imperceptible lag. Google Docs takes a good 2-3 seconds to spin up a UI on my i7.

You both do realize that similar arguments could have been made back in the day when moving from, say, command-line DOS applications to Windows API applications - right? Ultimately, computing has always been one of abstraction from the lower "layers". Taken far enough, one could spuriously argue that if you aren't soldering together the flip-flops that make up your logic and memory, you just aren't being efficient...

>You both do realize that similar arguments could have been made back in the day when moving from, say, command-line DOS applications to Windows API applications - right?

No, we don't. With Windows API there's no sandbox and extra embedded language overhead (it's still native code like in DOS, and even optimized better, able to use more available memory than DOS would allow, etc.).

Oh, and you also got the benefit of a FULL graphical interface over DOS. Here you have slower performance, extra cruft, bad apis AND the same final output (as a GUI app).

Not to mention that the Windows API UI toolkit, while bad, is sane compared to the web stack.

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

#163

Post by Touche »

Philipp__ wrote: post #50
Touche wrote: post #35

Earlier quoted context omitted.

> Wouldn't it be better to make native application Better in what way? The market has voted with their downloads, they don't agree that the problems with Electron apps are as bad as you feel that they are.

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.

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

#164

Post by brilliantcode »

TeMPOraL wrote: post #78
brilliantcode wrote: post #18

Earlier quoted context omitted.

well if you've ever built a cross platform native desktop application, you will appreciate Electron. Java Swing. Never again. edit: Do people downvoting even know what it's like building cross platform desktop applications using Java Swing? It's fucking awful, and that's a fact. Even the end result UI design look & feel is butt ugly. Sure you can spice things up with JavaFX but why? Do you not realize how masochistic…

Swing was at least meant to do UI. Web stack is not ; webapps are essentially a pile of ugly hacks on top of a document rendering engine, and it really, really shows - especially when you have webapps pretending to be native (e.g. webview-based apps on mobile). Also, for Java there's JavaFX (a de-facto standard UI toolkit for Java), which is very nice to work with.

Intention is in the hands of the builder not in it's inherent design.

> webapps are essentially a pile of ugly hacks on top of a document rendering engine

That's your own opinion. You claimed Java Swing & FX was the correct way and that thin clients like Electron is wrong. I disagree.

If Swing was meant to do UI then it's probably the most awful and inefficient way to do it.

If Web was not meant to do UI but it's the fastest and more efficient to work with than Java.

It's a matter of opinion but with starkly different development experiences. Sure, you can build using Java Swing/FX but you are going to get a completely different demographic and developer culture...one that is still ingrained in the era it was released.

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

#165

Post by gmfawcett »

dahauns wrote: post #95
ue_ wrote: post #39

Earlier quoted context omitted.

Emacs is a little harder to write plugins for, but it runs natively and the only impediment is that more people know JS than they do elisp.

Lots of emacs functionality runs via its lisp VM. I'd hardly call that 'native'. I mean, Emacs had jokes about being bloated decades before Javascript (and Java, another contender for these jokes) even existed. :)

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, though, is an inner platform effect: Emacs is the platform, there isn't a second one underneath (no browser engine).

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

#166

Post by mbel »

Spivak wrote: post #117
TeMPOraL wrote: post #78

Earlier quoted context omitted.

Swing was at least meant to do UI. Web stack is not ; webapps are essentially a pile of ugly hacks on top of a document rendering engine, and it really, really shows - especially when you have webapps pretending to be native (e.g. webview-based apps on mobile). Also, for Java there's JavaFX (a de-facto standard UI toolkit for Java), which is very nice to work with.

And yet that hacked together document rendering engine manages to be less painful to use than the the current show of UI toolkits. I think we'll get there eventually but until a native toolkit presents an interface as easy to use as the web developers are going to take the path of least resistance.

> I think we'll get there eventually but until a native toolkit presents an interface as easy to use as the web developers are going to take the path of least resistance.

Like Qt did with QML? http://doc.qt.io/qt-5/qml-tutorial1.html

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

#167

Post by braveo »

jacquesm wrote: post #152
cuckcuckspruce wrote: post #143

Earlier quoted context omitted.

It depends on what efficiency buys you, and what you trade efficiency for. When Windows was developed, we had enough CPU power to do the basic tasks people wanted done with a computer at a reasonable speed - the idea was that spare capacity was being traded for user friendliness. For some applications, even today, when maximum efficiency is necessary, purpose built machines ('soldering together the flip-flops that ma…

> When Windows was developed, we had enough CPU power to do the basic tasks people wanted done with a computer at a reasonable speed - the idea was that spare capacity was being traded for user friendliness. And in many cases that led to an instant drop in productivity. Those old green-screen systems were not pretty but they were quite efficient to use.

I've actually witnessed a very large oil & gas company switch over from those old dos programs to a new win32 program, and to a man, every person who had any experience on the old system bitched about how much slower it was to get anything done.

Having worked on the system myself, they were right (this was as a noobie to both systems).

There is something to be said for a small, tight system.

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

#168

Post by StreakyCobra »

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…

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. People simply used "pdf.js" to integrate PDF support in VSCode. Because it is web based it should have been straightforward to do. Doing the same with native technology would have took several weeks of coding, and it wouldn't have been cross-platform.

Imagine all the web-based open-source tools that could potentially be integrated in these editors. Integrating a SVG editor in native text editors would be a nightmare. With web-based text editor you can potentially just incorporate an existing tool like [1].

There are lot of other examples like this: Live markdown preview, mini-map, color-picker, integrated VSCode debug panel, …

It is also quite easy to add visual stuff. For instance adding a vertical bar at 80 characters in the background is quite easy to do with web technologies. On the other side emacs has still not managed yet to make the html-mode work nicely with this "fill-column-indicator". It is also probable that it would be much more easy to integrate web services (trello, github, …) directly within VSCode.

At the end people wanting performances have already quite a lot of choice in native text editors (vim, emacs, sublime…), and people who prefer functionalities can go with web-based text editors (atom, vscode, …)

[1] https://svg-edit.github.io/svgedit/releases/svg-edit-2.8.1/s...

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

#169

Post by DonHopkins »

YCode wrote: post #73
randiantech wrote: post #59

Earlier quoted context omitted.

VS Code IS a viable option. I use it daily basis and works great.

Seriously, coming from Visual Studio VSCode is a breeze of fresh performant air. Anecdotally I was able to create the cursor problem by minimizing/showing the VSCode window while viewing CPU usage DESC in task manager, but the effect was only ~2% usage for me (i7 processor). If one invisible (from a UX perspective) bug is VSCode's big performance problem then I'll gladly let it eat away at 2% of my CPU until it's fix…

Plus the fact that it's actually possible to use the profiler and debugger built into VSCode to profile and reflect upon itself, then drill down into its own live data structures, source code and css to discover and fix what was slowing it down.

I once wrote a visual PostScript debugger for NeWS, which I primarily used for debugging itself. [1]

[1] http://www.donhopkins.com/drupal/node/97

The PSIBER Space Deck is a programming tool that lets you graphically display, manipulate, and navigate the many PostScript data structures, programs, and processes living in the virtual memory space of NeWS.

The Network extensible Window System (NeWS) is a multitasking object oriented PostScript programming environment. NeWS programs and data structures make up the window system kernel, the user interface toolkit, and even entire applications.

The PSIBER Space Deck is one such application, written entirely in PostScript, the result of an experiment in using a graphical programming environment to construct an interactive visual user interface to itself.

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

#170

Post by onli »

juandazapata wrote: post #97
onli wrote: post #62

Because it hasn't been mentioned yet, as far as I could see: Blinking cursors are horrible and should never exist, it resembles torture. http://www.jurta.org/en/prog/noblink is an extensive list with ways to deactivate it in various programs. Try it out, you will feel the difference.

I don't like XXX, so it shouldn't exist it's a great argument.

No, of course not. It wasn't supposed to be the argument. Are you really interested in the background? I will just assume so, this is HN after all.

Our brain has some special recognition for specific things. A collection of those things are bundled under Gestalt psychology. There are also a number of things that make something pop out. Now, movement triggers the pop out effect, it is one of those things that we notice immediately. What that means in practice is that a blinking cursor in an otherwise plain image will be noticed immediately, and it takes conscious effort to ignore it. That is a strain on your mental capacities, and highly unnerving, even if you are not completely aware of what it is that annoys you.

Parts of this is what motivates those specialized writer editors, that remove everything apart from pure trext to make it as easy as possible to focus on the task at hand.

Blinking cursors, and this is what the jurta page mentions, also resemble the chinese waterdrop torture. I think that was meant a bit tongue in cheek, but is actually not wrong. It comes again and again and again and again ..., and it not immediately controllable.

Add to that the useless resource usage like in this bug and yes, I stand to that and am serious about it: Blinking cursors are a very bad habit that should just die out. And developers that actively implement it without making it deactivable should ask themselves what they are doing - I had that with Sharelatex, a platform which I otherwise like a lot.

Post reply on HN