Live data from Hacker News

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

github.com

691–700 of 801 posts

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

#691

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 wrong and don't know what you're talking about.

I dislike the implementation of Atom and have been highly critical of it on HN, even crashing a release thread once by pointing out how harebrained it is to implement complex text layout on top of browser APIs when the browser has access to a much richer text shaper itself - we'd know because we wrote it for Qt originally.

Because I've also worked on KDE for 12 years, wrote a big chunk of Plasma 5 and am one of the people porting it to Wayland. We want Wayland for many of the same reasons that make Atom bad, such as state synchronization problems and overhead with X11 (along with its very dire security story).

The intersection you suggest isn't real or doesn't matter. No one working on Wayland uses Atom.

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

#692

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…

[deleted]

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

#693
Why don't all those who complain about Electron apps get together and make a FOSS, cross-platform editor with all the features and an equal or better interface than VS Code and Atom?

If you use the time you now spend complaining to code instead, you should have the basics covered.

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

#695
post #246

Earlier quoted context omitted.

VSC is not even close of being as snappy as Sublime Text. Sublime also dominates when opening large files (2GB+) and searching trough them.

Agreed, except for the domination; true on linux afaik but not on windows: working with the large files is ok but opening them takes ages. VSC is definitely faster there.

You are probably right. I've used Sublime only on Mac and Linux. On Windows I was using another great, native application - Notepad++. It was as fast (or maybe even faster) as Sublime on other platforms.

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

#696

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. 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…

> 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 could have done that 20 years ago with COM components already. There was a thriving ecosystem where you could get a component for just about everything. Similar technologies were available on other platforms than Windows, like Bonobo (Gnome), Kparts (KDE), and whatever Mac had. It's a bit of a sh…

You also had to pay 100$ per copy of the COM component. Most of the web stuff is free, and you can just right click and view source. In NodeJS and NPM there are hundreds of thousands of components/modules that you can use for free.

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

#697
post #691

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 wrong and don't know what you're talking about. I dislike the implementation of Atom and have been highly critical of it on HN, even crashing a release thread once by pointing out how harebrained it is to implement complex text layout on top of browser APIs when the browser has access to a much richer text shaper itself - we'd know because we wrote it for Qt originally. Because I've also worked on KDE for 12 y…

I don't think one should take obvious satire to seriously. There's not enough time in the day to point out details in posts that are written just for laughs.

However, just to be pedantic ( ;-) ), I'll have to point out that "a big part of the people defending VSCode in this post agree that X11 is slow" does not imply "a big part of the people agreeing that X11 is slow defend VSCode in this post". The two aren't commutative, since one set of people is quite likely much larger than the other.

Edit:

Oh, and since you mentioned working on Plasma for over a decade: Thank you for making awesome FOSS! :)

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

#698

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.

> 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.

When you find yourself having to reimplement a blinking cursor, that's when you know you are working on a shitty tech stack.

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

#699

The answer to all this is: "use Qt". "But camgunz, I only know JavaScript" That's cool! Look into QML. "But camgunz, I only know X" That's cool too! Qt4 has a truly ludicrous number of language bindings: https://en.wikipedia.org/wiki/List_of_language_bindings_for_... . Qt5 has a fair number too: https://wiki.qt.io/Language_Bindings . "But camgunz, I need an embedded browser" I agree, separate windows are for savages.…

> use Qt

It has only been few years since a bug in file copy animation in systray that caused 100% cpu utilization in KDE Plasma 4 has been fixed. It wasnt the first bug in this regard nor it was the last one (IIRC. I saw a similar one in Plasma 5 too, though I didn't check it). Qt is old but cant say it is efficient or optimized. Qt5 programs that use classical QtWidgets have significantly more memory consumption than the programs written in other toolkits, and the newfangled Qt quick widgets is a fucking disaster as can be seen from the aforementioned bug they couldnt even get a simple screen animation straight, so not at all different than Electron ( only few years ahead of them)

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

#700

The answer to all this is: "use Qt". "But camgunz, I only know JavaScript" That's cool! Look into QML. "But camgunz, I only know X" That's cool too! Qt4 has a truly ludicrous number of language bindings: https://en.wikipedia.org/wiki/List_of_language_bindings_for_... . Qt5 has a fair number too: https://wiki.qt.io/Language_Bindings . "But camgunz, I need an embedded browser" I agree, separate windows are for savages.…

[deleted]
Post reply on HN