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

421–430 of 801 posts

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

#421

Post by santaclaus »

dheera wrote: post #382
stickfigure wrote: post #240

Earlier quoted context omitted.

Except that the abstraction layer for the user has remained the same. This is absolutely not true. Going to windowing GUIs from character-mode DOS was a massive usability improvement. No more exotic ctl-alt-function key combos (or control-control sequences for WordStar users like me). Going from desktop apps to webapps changed the abstraction layer of how we access and share documents. No more installing software on…

> Going to windowing GUIs from character-mode DOS was a massive usability improvement. No more exotic ctl-alt-function key combos cough Blender ...

Well, that is true of nearly all 'pro' creative apps. Maya, Illustrator, ...

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

#422

Post by pcwalton »

throwaway2048 wrote: post #400
pcwalton wrote: post #300

Earlier quoted context omitted.

> Not to mention that the Windows API UI toolkit, while bad, is sane compared to the web stack. Completely disagree. Charles Petzold's HELLO.C is hundreds of lines of code. Hello World on the Web is, well, "Hello world!". "Sane" environments don't force you to make up a distinction between "long pointers" and "pointers" if you want to conform to the house style in order to match 16-bit x86 real mode. Or route all eve…

Complaining that win32 has to do stupid things to get basic features in comparison to the web seems pretty laughable.

Why? The consensus opinion here seems to be that Win32 is a better API than the Web. I'm pointing out that this is an extreme case of rose-colored glasses.

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

#423

Post by pjmlp »

digi_owl wrote: post #230
na85 wrote: post #182

Earlier quoted context omitted.

>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? Ugh, reddit's standard, snarky response: "you do realize... right?" There's simply no way to get around the fact that by and large, many in-browser apps are poorly performant by any modern standard. To me, it seems like there's a faction within the…

The benefit is to their paymasters, as they get to extract rent (either directly or via ads) without having to contend with software pirates because the actual software logic is sitting pretty in a server cluster somewhere. Effectively we are back to the world of time-share terminals.

And they get to use open source libraries without having to share any single piece of their changes.

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

#424

Post by dom0 »

StreakyCobra wrote: post #271
coldtea wrote: post #179

Earlier quoted context omitted.

> 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 You know where else you could do the exact same thing AND have a 10x faster and 10x more memory/battery efficient editor? If a native editor just gave you a webview tha…

> 10x faster and 10x more memory/battery efficient editor? Except for the startup time --- with which I can live with --- I never felt a difference in speed between native text editors ans VSCode. There is one, but I don't notice it. Human are much more slower than computers, so as long as it is not taking more time that I need to notice it, I don't care. Nowadays my computer has enough memory so I can afford to not…

> Battery could be problematic indeed, but before looking at my text editor, I would probably first switch from KDE to i3, and then use a lightweight web browser. This would impact it much more than my text editor.

This item is about VS Code consuming 13 % CPU when idle, which is bigger than the difference in idle CPU between KDE and i3 (if you don't have fancy widgets, it's about ~nil).

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

#425

Post by coding123 »

kardashev wrote: post #315
jstarks wrote: post #274

Earlier quoted context omitted.

What hardware or operating system changes do you think are necessary to improve the GUI development experience?

Imagine being able to create windows, draw, deal with io devices (keyboard, mouse, controller, etc.) and do OpenGL graphics type work with system calls. That would allow (practically) any language to trivially create native apps with a GUI, at least trivially compared to today. In Linux we could eliminate the multitude of complicated display servers and reduce latency in the system (making VR and AR easier to do). Wi…

I have also been waiting for the day... Maybe in a few years this Linux subsystem for Windows will start to mold things in this direction?

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

#426

Post by pcwalton »

jblow wrote: post #407
pcwalton wrote: post #310

Earlier quoted context omitted.

> instead of a native widget that writes directly to the screen. "Writing directly to the screen" (by which I assume you mean writing pixels one by one to the framebuffer) is a bad idea for modern graphics hardware. It was fine on the 486, but nowadays you need the ability to do global optimizations for good 2D (or 3D) graphics performance. Ironically, the Web stack is much better positioned to do this than, say, Win…

It seems reasonable this might be true, but it's not. In video games we went down the road of retained-mode graphics APIs (declarative-type things, so that they can do the kinds of 'global optimization' you mention) but we abandoned them because they are terrible. Video games all render using immediate-mode APIs and this has been true for a very long time now and nobody is interested in going back to the awful retain…

You build custom retained-mode APIs on top of the immediate mode APIs—they're called game engines.

What happens if you try to present an immediate mode API for UIs is the status quo with APIs like Skia-GL. You frequently end up switching shaders and issuing a new draw call every time you draw a rectangle, and you draw strictly in back to front order so you completely lose your Z-buffer.

Imagine if games worked like that: drawing in back to front order and switching shaders every time you drew a triangle. Your performance would be terrible. But that's the API that these '90s style UI libraries force you into. Nobody thought that state changes would be expensive or that Z-buffers could exist when Win32, GTK, etc. were designed. They strictly drew using the painter's algorithm, and they used highly specialized routines for every little widget piece because minimizing memory bandwidth was way more important than avoiding state changes. But the hardware landscape is different now. That requires a different approach instead of blindly copying what the "native" APIs did in 1995.

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

#427

Post by royjacobs »

krylon wrote: post #398
Zenst wrote: post #361

Earlier quoted context omitted.

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…

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.

Having minigames during loading or installation was actually patented by Namco for Ridge Racer, I believe. I'm not quite sure about the details since I seem to recall things like invade-a-load on my Commodore 64 at least a decade earlier, but there you go.

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

#428

Post by equasar »

SippinLean wrote: post #289
Skywing wrote: post #149

Ah yes. The classic text editor debate thread. In this thread you can expect to find folks claiming that 2 seconds of startup time for editors, like Atom, is so disruptive to their workflow that they'd rather use notepad.

I've switched to VSCode as my go-to text editor and you understate the real impact the poor performance has on my workflow. It's not just startup, almost everything has a 250ms-2s delay; it's not a lot each time but it adds up and is frustrating.

VSCode best use is not for text-editing, its main target is to work as an small version of a full-blown IDE. Use the right tool for the job.

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

#429

Post by pointernil »

Thinking about "the stack", runtimes , development processes and the root-causes involved here i think, the best thing that could happen to "the industry" is some event preventing the silicon production to deliver new cpu-s/ram/gpu-s/harddrives for some 5+ years or so.

Constrain the resources to bring brack some sane levels of efficiency regarding ram/cpu-cycles/hd-space.

/scnr

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

#430

Post by Wofiel »

MichaelGG wrote: post #284
antisthenes wrote: post #237

Earlier quoted context omitted.

Excel loads in ~1 second...and doesn't have UI lag after it does. Try working with large data sets in Google Docs and you'll have that 2-3 second lag time with _every_ operation you perform.

On the flip side, the new Windows "Metro" style calculator app takes several seconds to load ... and is less usable than the old calc.exe.

I've found this so often, I have a dual Xeon and 16GB of RAM and a calculator of all things taking more than a second is unacceptable.

I got a popup inside the calculator asking for feedback about it once with an inbuilt form and submission. I can only assume it has toooooons of hidden away cruft that does everything but assist in calculating things.

Post reply on HN