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

771–780 of 801 posts

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

#771

Post by tnone »

bitwize wrote: post #623
kchoudhu wrote: post #516

Earlier quoted context omitted.

I think a recursive n-gate situation would be delightful. Someone should make this happen.

Some internets post weekly bitter satires of Hackernews to the internets. Hackernews finds it and misses the point entirely, of course: Hackernews is being laughed at , not with .

An internet finds a bitter satire of his industry and is endlessly amused at taking the piss out of sincere but naive youngsters who debate technical concerns without understanding the appropriate context and history. The mocker misses the point entirely: Hackernews didn't fail, the generation that came before did, in letting their culture die.

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

#773

Post by framp »

StreakyCobra wrote: post #168
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…

This is wrong. The world on the other side is so much greener.

https://wiki.qt.io/Handling_PDF#Using_QtPDF

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

#774

Post by pvg »

Kiro wrote: post #772
pvg wrote: post #751

Earlier quoted context omitted.

There's nothing to elaborate. They're both Java/Swing apps.

Thanks. That's what I meant. I thought that counted as native.

Nope, it doesn't. Although it's probably a good indication that the hairsplitting over 'native' and not is not as important as this thread might make one think.

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

#775

Post by allover »

allover wrote: post #770
KirinDave wrote: post #752

Earlier quoted context omitted.

It's unfortunate that your opinion–that of the two most successful programmer's editors currently in use today are doing something right–is being heavily downvoted by people who object to the "web" invading on their territory for reasons unknowable. "Eating too many CPU cycles while idle" is a problem many, many text editors have faced. It's purely an unfair bias in this case that this is justification for trying to…

Yes it is sad that it is one of those topics that HN users seem incapable of discussing objectively. Meanwhile Electron usage grows and grows, and will continue to until someone comes up with a viable alternative.

If you disagree, tell me what I should use instead of Electron, that is feasible to use for a small team to have a wide platform reach, and with a community comparable to even just the 'React' part of web dev.

The drive-by downvotes really just prove my point.

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

#776

Post by KirinDave »

reitanqild wrote: post #587
allover wrote: post #552

Earlier quoted context omitted.

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.

As someone who maintain other peoples code I really don't look forward to deal with js a few years from now: What build system did they use? Where is that package? Does it even exist anymore. Etc. Had similar problems trying to maintain a delphi project as an almost fresh from scool developer. At that point I understood the value of Java and Maven.

It's true, but there is an interesting mitigating effect here. If at some point you come across an old project that appears to be a product of herculean effort, note that these days its a matter of a few days effort.

The platform that JS is based upon moves incredibly fast.

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

#777

Post by nonsince »

btschaegg wrote: post #697
sho_hn wrote: post #691

Earlier quoted context omitted.

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

I'd say you absolutely have to point out factual flaws in comedy. Comedy is truth, that's why you probably believe that David Cameron put his penis in a pig's mouth and Donald Trump was peed on by Russian prostitutes. There's no evidence, but it's funny so you believe it anyway.

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

#778

Post by digi_owl »

audidude wrote: post #754
digi_owl wrote: post #742

Earlier quoted context omitted.

Could have sworn that there exist multiple takes on extensions for that, but none that has been rolled into Xorg proper. This either because lisencing, or because the current devs have GPU stars in their eyes. BTW, it is downright funny how just about every Gnome guy i have encountered online seems to come across a pedantic grump. that would not know a joke if it fell on his head...

Interesting how one person is a common denominator in all those interactions ;)

And most of the comment gets ignored for a cheap retort, as expected.

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

#779

Post by Qwertious »

abiox wrote: post #609
stock_toaster wrote: post #559

Earlier quoted context omitted.

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

> Use the right tools for the job i wonder if this expression constitutes a thought-terminating cliché.

It sounds a bit like one, but I think the point is that while the web can be used for everything, that doesn't mean it should. Like if we built XML into filesystems directly, instead of doing it just in the layers above.

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

#780

Post by trishume »

jblow wrote: post #765
trishume wrote: post #631

Earlier quoted context omitted.

This argument looks like you and pcwalton are arguing about different definitions of "immediate mode API". I think both of you agree with each other on object-level propositions. pcwalton seems to be presuming that part of the contract of an "immediate mode API" is like old-school ones it actually immediately draws to the frame buffer by the end of the call. Whereas you are talking about modern "immediate mode API"s…

"so you need some data structure that sticks around between frames specific to the widget type, so that's what retained mode APIs like Qt do for their widgets." Immediate mode GUI systems are allowed to keep state around between frames and the most-featureful ones do. The "immediate mode" is just about the API between the library and the user, not about what the library is allowed to do behind the scenes. The argumen…

I'm definitely aware of this, it's why I mentioned "varying levels of caching". The Conrod imgui that I mentioned basically uses retained mode GUI data structures behind an immediate mode API through diffing for performance reasons.

This works just as well/quickly as a retained mode API in almost all cases. There's some cases like extremely long tables with varying row heights and sortable columns, where you need an efficient diff of the table contents. Since recalculating layout and sorting every frame is inefficient. Retained mode APIs do this with methods to add and delete rows. It's possible to do with an immediate mode API, but to detect differences in the rows passed in quickly you need to use a functional persistent map data structure with log(n) symmetric diff. Or you can just have an API that is mostly immediate mode but has some kind of "TableLayout" struct that persists between frames and is modified by add and remove functions.

I'm curious what API you would use for implementing a table with varying row heights (that you only know upon rendering but can guess beforehand), sortable columns and millions of rows. I implemented this in an immediate mode GUI API a few months ago, and I did it with persistent maps and incremental computation in OCaml. Incrementally maintaining a splay tree and a sorted order by symmetric diff of the input maps. This isn't as nice of an API in languages like C++ so I'm wondering if there's a better way.

Post reply on HN