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

591–600 of 801 posts

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

#591

Post by pjmlp »

pcwalton wrote: post #442
pjmlp wrote: post #417

Earlier quoted context omitted.

You are forgetting the magic CSS incantations, which are browser and version dependent, to accelerate something that is just granted on any native UI toolkit.

I agree that the paint/compositing distinction is bad (see my reply to Paul Irish), but Win32 has just an opaque a distinction. GDI is much worse for modern hardware acceleration than the Web is.

GDI is a dead worse, already replaced by better solutions for anyone that cares to use them, yet it still scales better than most web stuff.

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

#592

Post by Razengan »

problems wrote: post #531
KirinDave wrote: post #492

Earlier quoted context omitted.

I'm glad at least we made fun of both sides. I really wish there was a good option for GUI toolkits. Nearly all are either too primitive to make more than freshmen college (or tenured physics professor) level work or asymptotically approach web browsers without all that tedious attention to improvement and accessibility.

Qt pretty much nails this balance, WPF isn't bad either. Both will run circles around browsers at rendering performance and are much less tedious to develop in unless you've only done web dev before.

AppKit/Cocoa is very good too, if not cross-platform. Consistent, dynamic, extensible, and there's so much your apps get for free, and new features often become retroactively available for past apps, like when NSDocument got autosaving, and now tabs for multi-document apps, the wide-gamut-aware color pickers and so on.

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

#593

Post by reitanqild »

aerique wrote: post #443
krylon wrote: post #398

Earlier quoted context omitted.

Broken Sword let you play Breakout during the installation; it was such fun (I had not played Breakout in a long time at the point) I was almost sad when the installation was finished. ;-) I have often wondered since why this was not a more popular way to deal with long running installers.

I think it's because Namco had a patent on games in loading screens from 1995 to 2015: http://kotaku.com/the-patent-on-loading-screen-mini-games-is...

Ghostbusters game on c64 had it when I bought it used in 1991 or 92 I think.

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

#594

Post by josephg »

khedoros1 wrote: post #530
posterboy wrote: post #503

Earlier quoted context omitted.

> the old stuff worked just fine > we don't need the new stuff > how about we throw both away to shut everyone up, would that make either side happy?

How about: Take what we learn from new development so that we can improve the older, lower-level stuff, and strip away some unnecessary levels of abstraction?

Yep. I did some swift development recently and while I absolutely loved the language I was struck with how much worse the uikit APIs are compared to react.

There's nothing special about javascript the language. The nice thing about web development is that the really fast framework iteration cycles. And everyone complains about them, but as a result we have some fantastic APIs for UI development in javascript land now. (Eg, react.)

What I want to see is someone port those lovely abstractions across to native languages. For example, a port of choo[1] to swift on top of uikit would be gloriously fast, efficient, small and easy to work with.

[1] https://github.com/yoshuawuyts/choo

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

#595

Post by flukus »

ldev wrote: post #555
zbuf wrote: 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…

I think that's a case of necessity being the mother of invention. IME the windows 10 drivers crash much more frequently than the linux or windows 7 ones ever did.

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

#596

Post by bitexploder »

ldev wrote: post #555
zbuf wrote: 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…

FWIW my graphics drivers crashes on Ubuntu always recover. Even a complete GPU hang. It sees the driver is hung and restarts it causing a few seconds of minor glitching.

Configuring X is not for the faint of heart, but in Unity it is basically magical and deals with HiDPI displays, etc. just fine. Feature for feature it is very similar to Win or Mac on the display and GPU driver front. The total package still feels rougher around the edges, but it is still good.

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

#597

Post by FridgeSeal »

iaml wrote: post #548
ovao wrote: post #479

Earlier quoted context omitted.

That's an unusual experience. Based on a handful of benchmarks[0] done by the author of JOE, VS Code is sometimes an order of magnitude slower than Notepad++ and Sublime at some tasks. I use VS Code pretty much exclusively these days myself, so I'm not picking on it by any means. [0]: https://github.com/jhallen/joes-sandbox/tree/master/editor-p...

I have the same experience on my pretty slow laptop. Granted, my projects aren't big, but I would take vs code over sublime any day. Interestingly, atom feels much slower compared to both.

That's because, unequivocally, atom is slower.

https://pavelfatin.com/typing-with-pleasure/

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

#598

Post by flukus »

problems wrote: post #531
KirinDave wrote: post #492

Earlier quoted context omitted.

I'm glad at least we made fun of both sides. I really wish there was a good option for GUI toolkits. Nearly all are either too primitive to make more than freshmen college (or tenured physics professor) level work or asymptotically approach web browsers without all that tedious attention to improvement and accessibility.

Qt pretty much nails this balance, WPF isn't bad either. Both will run circles around browsers at rendering performance and are much less tedious to develop in unless you've only done web dev before.

A project I've been keeping my eye on is libui (https://github.com/andlabs/libui), it's basically a thin wrapper around the native libraries (very SWT like) that can be used in a number of languages.

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

#599

Post by flukus »

skc wrote: post #579
problems wrote: post #531

Earlier quoted context omitted.

Qt pretty much nails this balance, WPF isn't bad either. Both will run circles around browsers at rendering performance and are much less tedious to develop in unless you've only done web dev before.

Such a pity that WPF was never ported to other platforms That's a UI framework that was done right in my opinion. Fast, incredibly flexible and sane. That it's been relegated to boring internal only enterprise app development is pretty sad. I enjoyed working with it immensely.

It also suffers similar problems to the one posted here (or at least used to), an idle app will consume quite a bit of CPU.

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

#600

Post by BHSPitMonkey »

flukus wrote: post #595
ldev wrote: post #555

Earlier quoted context omitted.

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

I think that's a case of necessity being the mother of invention. IME the windows 10 drivers crash much more frequently than the linux or windows 7 ones ever did.

I don't think it's fair to blame the OS for driver crashes. Those are a result of third parties and can happen on any platform.
Post reply on HN