Live data from Hacker News

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

github.com

701–710 of 801 posts

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

#702

Earlier quoted context omitted.

"Copying pixels" is the dominant mode of operation in other remote GUI protocols like RDP, so it's not the end of the world.

Actually, RDP is GDI over the wire, which is not too dissimilar from X. RDP has efficiency gains because clients send pixmaps over the wire to be stored on the server, and then send draw calls to display those pixmaps in certain places, composing a display. You can do this with X11 too, but the GTK developers don't want to because using the protocol is hard ;_;

[deleted]

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

#703

Earlier quoted context omitted.

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.

Keep in mind though, that the performance optimization the Windows article talks about is how to reduce the working set in memory more than the CPU consumption.

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

#704

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.

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

> Trying to shoehorn everything into "the web"

'Trying to shoehorn' is just your opinion.

> Use the right tools for the job.

What does that non-sequitur even mean in this context? Use a different native platform to write each native version of the app? That simply isn't viable for anything but very large companies.

Or should I use Qt, with it's tiny support community?

Also why is React/React-Native not 'the right tool'?

> [...] just as shitty as the web.

Again your opinion. In my opinion the web is a joy to work on compared to the cesspool that is native app development.

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

#705

Earlier quoted context omitted.

"Copying pixels" is the dominant mode of operation in other remote GUI protocols like RDP, so it's not the end of the world.

Actually, RDP is GDI over the wire, which is not too dissimilar from X. RDP has efficiency gains because clients send pixmaps over the wire to be stored on the server, and then send draw calls to display those pixmaps in certain places, composing a display. You can do this with X11 too, but the GTK developers don't want to because using the protocol is hard ;_;

gtk+ certainly does use server-side textures and positioned draws. That is why the documentation is so adamant about using API like create_similar_surface().

Even the pixelcache uses server-side textures when available.

This is what Xshm does and why everything modern uses it. You get a server-side texture, but mapped into client address space so you can do direct draws and then XCopyArea() into your final location for double-buffering.

But gtk+ isn't really in the position to be able to control everything so precisely all the way down the driver stack to network transparency layers. So unless you connect to our process directly, like the HTML5 broadway backend, there is only so much we can do.

The broadway backend does employ various techniques to reduce the amount of content passed using a sort of rolling hash.

https://git.gnome.org/browse/gtk+/tree/gdk/broadway/broadway...

I expect forthcoming app/display network transparency layers in GNOME's Wayland compositor to employ a similar strategy.

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

#706
post #629

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.

Fair enough, but double-digit usage of an entire core... when the program is IDLE? how can you justify that? That's just broken.

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

#707

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.

Because there are good enough tools out there already, foss and commercial. This problem is solved already.

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

#708
post #555
post #534

Earlier quoted context omitted.

Best bit is that X11 runs really well these days -- responsive, fast, reliable. Emacs runs great, gitk, xterm, xosview, mplayer window manager, even Firefox is alright. Renoise, Maya, Blender too. Not to mention network transparency when I need it. It's a great environment to get my work done, and 3x hi res displays is the stuff I dreamt of 15 years ago. So it's a good job we're about to throw it all out and start ag…

> X11 runs really well these days -- responsive, fast, reliable Well, you haven't seen Windows then - the graphics stack is phenomenal and a marvel of engineering. nVidia drivers crash? I only get a second of black screen and then resume my work. Yep, that's right - no other GUI program crashed, I didn't had to do anything, literally just 1 second of black screen. Oh and you can have one window on two monitors and bo…

As someone who remembers NT4 video driver crashes bringing down the whole system, when I saw Windows 10 recover from a video driver (yes, nVidia) crash I was massively impressed.

There's always room to improve but I'm really happy with the stability improvements they've put in.

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

#709

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.

Because there are good enough tools out there already, foss and commercial. This problem is solved already.

Name them.

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

#710
post #500

Earlier quoted context omitted.

An interesting observation. But isn't the explanation rather obvious? Writing desktop applications to sell for money, that has quietly disappeared. It still exists, somewhere, but so does horseshoe-fitting (the few experts are probably making decent money, but it's a zombie business nonetheless). Between a few established offerings that won't be looking for a new framework any time soon, desktop-packaged web and all…

Yes, I know why it's the case nowadays: at my work, for example, I occasionally touch all the major areas of modern software development — server backends, mobile, Javascript-in-the-browser and meta-software for writing software — but I've never done what the average person, and maybe even I, would think of when they hear the term "software development." And it does seem very very strange. I'm imagining this Socratic…

Besides the fact that you can have reasonable UI in swing (look at IDEA), and that Java was designed for Solaris initially, and that Java is still way faster that any JS (sockets, compare-and-set primitives, +direct access to native memory, shared memory IPC and the like... which makes it prime candidate for server applications) it makes for a good example what an uneducated developer might say.
Post reply on HN