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

711–720 of 801 posts

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

#711

Post by sho_hn »

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…

:) Fair enough. I am a bit less cranky after my morning coffee now ;). Thanks for the warm words!

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

#712

Post by [deleted] »

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…

[deleted]

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

#713

Post by sah2ed »

insulanus wrote: post #576
jbtule wrote: post #533

Earlier quoted context omitted.

You know what would be fast for display updating, ncurses. I wonder why they didn't use that? If only we had an ncurses based text editor.

Someone should write a webkit based ncurses! Why haven't we seen the light before !? ;)

There is already an ncurses library for JavaScript [1] so one for WebKit shouldn't be far off ;)

[1] https://github.com/chjj/blessed

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

#714

Post by jahnu »

boterock wrote: post #643
charrondev wrote: post #567

Earlier quoted context omitted.

I don't much about graphic stacks, but in my experience the best, as least from the perspective of someone using multiple HiDPI displays macOS is far and away the best. Many windows applications don't scale properly or if they do they require special settings to do so. If you have monitors with different levels of scaling your going to have a terrible time on windows.

On the other hand, connecting a 4k display in windows will default to configure it at 200% scaling, in mac it defaults to render everything tiny as ants.

Windows 10 refuses to work properly with my 4K Dell monitor.

After it goes to sleep, then I wake it up all open Windows have been resized into a tiny part of the screen and scaling goes weird.

https://duckduckgo.com/?q=windows+4k+monitor+resize+after+sl...

Terrible.

Having said that on macOS my external 5K LG monitor is causing complete system crashes now and again :(

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

#715

Post by zigzigzag »

sfifs wrote: post #225
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.

Very simple, there's a couple of orders of magnitude greater number of developers and designers who have skill with web technologies than native UI. Similarly there's a couple of orders of magnitude more options of UI frameworks and design patterns. Add to the fact that Blink, Webkit, V8 and Chakra have been constantly pushing the bounds on speed bringing a web technology based front end within touching distance in t…

I still use Sublime. I've also used Atom and I didn't see any features it had that Sublime didn't. They're both very basic text editors, with the difference that Sublime is about 100x faster and less bloated.

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

#716

Post by TeMPOraL »

allenz wrote: post #629
chetanahuja wrote: post #612

Earlier quoted context omitted.

"3% idle sounds egregious but higher battery usage isn't a problem for most" Oh God this is why we can't have nice things. How the heck is someone actually justifying this stupid shit here?

What do you find stupid? The way I see it, HTML/JS is a pretty good higher-level GUI language, and much effort has been spent making it work well. The overhead is worth it if it makes developers more productive.

Is it? The costs which you offset with developer productivity get multiplied times the number of users, which is orders of magnitude more than number of developers.

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

#717

Post by zigzigzag »

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…

> Doing the same with native technology would have took several weeks of coding, and it wouldn't have been cross-platform.

I wrote a PDF viewer in Java(FX) in about one evening using PDFbox. There are also PDF components for practically any other desktop app framework you care to name, most of them older and more mature than pdf.js

The fact that so many devs express amazement at things considered utterly routine for decades is one of the reasons the entire web dev community is so often treated as a joke.

HTML has very few redeeming features as an app platform. It's way past time it gets killed by something better.

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

#718

Post by rimliu »

allenz wrote: post #629
chetanahuja wrote: post #612

Earlier quoted context omitted.

"3% idle sounds egregious but higher battery usage isn't a problem for most" Oh God this is why we can't have nice things. How the heck is someone actually justifying this stupid shit here?

What do you find stupid? The way I see it, HTML/JS is a pretty good higher-level GUI language, and much effort has been spent making it work well. The overhead is worth it if it makes developers more productive.

Why I agree on "much effort has been spent" it is very hard to agree about HTML which was meant to be used for marking up static documents combination with ad-hoc scripting language being "pretty good" for GUI. More like "possible to work around a bit".

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

#719

Post by zigzigzag »

m_fayer wrote: post #114
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…

Because Microsoft and Apple have both dropped the ball on their native UI toolkits. Right now I'm doing web frontend with TS+VueJS+nice CSS toolkit. Yes there's plenty of complaining to do about the fragile convoluted toolchain and crappy performance. But I still gladly take it over WPF (promising, abandoned for some reason) or Cocoa (feels a decade out of date). No major OSS community, no Material Design/Bootstrap/e…

You can also look at JavaFX. It's pretty good.

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

#720

Post by zigzigzag »

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.

Less painful according to who? From reading this thread it appears that most devs claiming it's incredibly easy have never actually worked with other UI toolkits at all, so their experience is largely worthless.

I've done web UI dev. I've also written code using GTK, Qt, Windows, Swing and JavaFX. A good modern UI toolkit like JavaFX or Qt blows the web stack out of the water on almost every metric. Developer productivity, correctness, speed ... you name it.

Post reply on HN