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

461–470 of 801 posts

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

#461

Post by jbmorgado »

mschaef wrote: post #393
jbmorgado wrote: post #53

Earlier quoted context omitted.

Pretty sure any sane software implementation of a simple seconds pointer would easily update faster than 1 Hz while using little to negligible CPU time in a Desktop processor from the 90's and onwards.

The Windows 1.0 clock (1988) had a 1Hz second sweep hand that ran on a 4.77MHz 8088. It's really just a couple clipped line segments each second. http://variableghz.com/wp-content/uploads/2012/12/windows-1....

Yes, that was the point I was making. This is something computationally trivial as long as the code is written appropriately.

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

#462

Post by dragonwriter »

allendoerfer wrote: post #437
dragonwriter wrote: post #355

Earlier quoted context omitted.

> In order to render HTML, CSS and JavaScript, you need an entire web rendering engine. Getting to piggyback on V8 and Blink work is, I suspect, often a benefit rather than a cost in the eyes of developers of Electron-based editors. Sure, it's bigger resource load, but for use cases where the performance is acceptable, it's a lot less developer load to get the functionality out the door.

Until you have to reimplement even blinking cursors.

No, even after that I'm pretty sure it's a net win in developer time.

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

#463

Post by brilliantcode »

dragonwriter wrote: post #328
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.

> 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 the presentation layer making life more difficult.

The latter is why Javascript is perceived to be "over engineered" by people viewing it nothing short of "fairy dust on ugly document pages" which is absolutely incorrect way of viewing application development.

I used to be the biggest Javascript skeptic but once I realized the intent behind React/Redux/Vue.js, it changed my perspective and have started treating it with more weight and respect.

Once that paradigm shift happened in my perception, I found it a lot easier to navigate and endure the fragmented tooling and endless variations of npm modules.

Because I realized that it's going to get better eventually and it's here to stay. Young people aren't learning Java & using Maven on Eclipse or Netbeans anymore. They are on Atom or Visual Code, writing Javascript.

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

#464

Post by quicklyfrozen »

rayiner wrote: post #130
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…

The web is in just a shameful state. Even with 300 mbps fiber internet most websites are not snappy. As in, pages are so slow to render that I'll start reading, but then lose my place when the page reflows as it continues to load. Or click on the wrong thing because the page reflowed while I was trying to click on something. As far as I can tell I'm actually CPU-limited, because I noticed no real difference from when…

It takes a while to source all the ads, and the reflow that leads you to click on the wrong thing (e.g. an ad) is most likely intentional.

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

#465

Post by saghm »

I always turn off cursor blinking everywhere I can because I find it distracting; I never knew I could use "performance" as an excuse!

On another note, why is cursor blinking such a universal thing? I assume that other people must like it, or else it wouldn't be so common. Do people have trouble finding their cursor without it, or do they have trouble distinguishing it from actual text? I've never had either of those problems with blinking turned off, but I can't think of any other plausible reason.

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

#466

Post by TillE »

smitherfield wrote: post #381
jug wrote: post #359

Earlier quoted context omitted.

Or, as a better example - rewriting from Electron to Qt rather than Win32. Obviously Electron was chosen to be cross platform. But I still don't get the web renderer obsession. We already have high perf cross platform solutions. Use them.

On a related note, it seems crazy to me that for actively maintained, cross-platform, native widget GUI libraries, your options are… Qt. (Not that Qt is a bad library, but it's bizarre that such an important area is so neglected by our industry).

It's a huge undertaking with a questionable business model, especially as most things have moved to the web and/or mobile. But it is amusing that there are way more free, cross-platform, high-quality game engines than GUI toolkits.

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

#467

Post by PopsiclePete »

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.

I've done some raw C Win32 GUI programming and I've done some modern electron stuff as well.

I know which I'd rather offer as my toolkit of choice for a project on which I wanted lots of people to contribute code to!

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

#468

Post by funkyy »

saghm wrote: post #465

I always turn off cursor blinking everywhere I can because I find it distracting; I never knew I could use "performance" as an excuse! On another note, why is cursor blinking such a universal thing? I assume that other people must like it, or else it wouldn't be so common. Do people have trouble finding their cursor without it, or do they have trouble distinguishing it from actual text? I've never had either of those…

I assume it is useful to determine where the cursor is. It is easier to spot blinking element rather than solid.

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

#469

Post by bitwize »

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 GUI implementation, and they can't live without the crutches VSCode provides when shitting out Go microservices.

Many of these same people will argue vehemently that X11, the shitty GUI layer for Linux that ran perfectly fine 20 years ago, is "slow" and "bloated" and needs to be replaced with Wayland, a new, completely different, shitty GUI layer.

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

#470

Post by TillE »

ApolloFortyNine wrote: post #49
tommoor wrote: post #29

Earlier quoted context omitted.

The benchmarks make it look bad but to be honest aren't that relevant for day-to-day use. I can't remember the last time I saw performance issues in Atom and the plugin infrastructure massively outweighs the occasional possible issue

The only ever time I see performance issues is when I accidentally click on a binary by accident. Atom's large file handling is awful... But how often do you open a 100MB text file?

Isn't VSCode's hard limit more like 30MB? I've tried using it as my only non-IDE text editor recently, and it's infuriating that it's completely impossible to open a lot of log files I deal with.

People here are really down on Sublime Text for some reason, but it can actually do everything I need.

Post reply on HN