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

491–500 of 801 posts

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

#491

Post by joshuamorton »

tomc1985 wrote: post #294
joshuamorton wrote: post #146

Earlier quoted context omitted.

I think the fact that you call java not-compiled, but python interpreted shows your misunderstanding in this area. Both run exactly the same way, they are compiled into an intermediate bytecode which is run in a "VM". The normal Java VM has a JIT, the normal python VM does not, but pypy does and achieves performance on par with some of your compiled languages, at the cost of reduced c compatibility. I know C, Java, p…

Uh, I lumped in Java with the compiled languages? And yeah, thats right there's like 80 million Python variants, some of which are compiled.

that was a typo. "not-interpreted" was my intended statement.

And I'd love for you to show me a python variant that is compiled in the same way that C is compiled. The closest is nuitka, which...isn't.

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

#492

Post by KirinDave »

bitwize wrote: post #469

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

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.

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

#493

Post by Eiriksmal »

kchoudhu wrote: post #473
bitwize wrote: post #469

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

If you could n-gate every article as it's posted, that would be awesome.

For those who missed it, n-gate satirizes some HN posts, to the delight of all: http://n-gate.com/hackernews/

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

#494

Post by michel-slm »

Zenst wrote: post #361
artursapek wrote: post #25

I'm reminded of this classic: https://github.com/npm/npm/issues/11283 NPM had a progress bar that was so fancy that it slowed down installation time (basically its only job) by ~50%. Hilarious. My mantra here is, if you find yourself thinking about implementing a fancy loading spinner/progress bar, it would be more productive to just spend that time making it unnecessary - speed up your shit! Obviously that doesn't a…

IBM spent a humongous amount of man hours upon the running man in smit under AIX, many of those consumed with making sure it ran correctly on all systems of various speeds without the animations going crazy. Alas I don't have exact man hours, but that was what one of the engineers told me a nearly 2 decades ago now. Hopefully somebody else has more detail upon this as one of the earliest examples of progress animatio…

One Linux distribution used to let you play Breakout during installation, but I forgot which one. Caldera, maybe?

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

#495

Post by pcwalton »

Dylan16807 wrote: post #471
pcwalton wrote: post #386

Earlier quoted context omitted.

CSS object-fit handles your first two complaints, and CSS Variables handles your last one.

Aren't CSS Variables just constants you can reuse? How are they going to let you set width to 80% and height to 2/3 of whatever that ends up being?

Because percentages in heights are usually relative to the width of the containing block.

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

#496

Post by Eiriksmal »

caoxuwen wrote: post #486
kchoudhu wrote: post #473

Earlier quoted context omitted.

If you could n-gate every article as it's posted, that would be awesome.

bummer n-gate didn't comment on its own hn post

I was really looking forward to that write up, as well. Unfortunately, the author must have some rule about not breaking the fourth wall. Or they avoid softballed summaries?

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

#497

Post by throwaway91111 »

cr0sh wrote: post #112
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.

You both do realize that similar arguments could have been made back in the day when moving from, say, command-line DOS applications to Windows API applications - right? Ultimately, computing has always been one of abstraction from the lower "layers". Taken far enough, one could spuriously argue that if you aren't soldering together the flip-flops that make up your logic and memory, you just aren't being efficient...

Yea, but that came with other benefits, like mandatory accessibility and unified look (at least on the mac). Where are they on the web? Does anyone proactively consider ARIA? Consistency of user interface is just a laughable dream.

But hey, thank god we finally have a framework we can inject ads in at will.

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

#498

Post by sqeaky »

lispm wrote: post #299
dahauns wrote: post #95

Earlier quoted context omitted.

Lots of emacs functionality runs via its lisp VM. I'd hardly call that 'native'. I mean, Emacs had jokes about being bloated decades before Javascript (and Java, another contender for these jokes) even existed. :)

The jokes of GNU Emacs being bloated are from a time when machines with 8MB RAM were modern. The original NeXT computer was introduced in 1988 with 8MB RAM... The Mac II from 1987 started at 1MB, max at 8MB, ... today phones have 2GB RAM.

I bought a phone with 6GB of RAM. It keeps getting bigger.

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

#499

Post by agumonkey »

I hope y'all never have the chance to boot Turbo Pascal 7.0 (DOS) on a P5 class cpu. It's pretty sad. I mean a 700KB IDE with decent language to native code with some form of live check, instantaneous compilation times, modular programming, online help; multiple windows and a cult classic color scheme. It hurts.

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

#500

Post by usrusr »

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

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 the gratis stuff, where would new GUI toolkits find their footing? Desktop means potentially offline and offline means almost all monetization schemes don't apply. (including those that don't work except for instilling hope in investors)
Post reply on HN