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

471–480 of 801 posts

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

#471

Post by Dylan16807 »

pcwalton wrote: post #386
dheera wrote: post #373

Earlier quoted context omitted.

Q: How do you make a video maintain an aspect ratio and fill up the width of a parent? A: Nested div hell. Q: How do you make an image maintain an aspect ratio and fill up the width or height of the screen, whichever comes first? A: Nested div hell and JavaScript. Q: How do you make a scaled background image stay put even when the keyboard input pops up on a phone? A: Supreme JavaScript, CSS, and div hell. Q: How do…

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?

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

#472

Post by StreakyCobra »

dom0 wrote: post #424
StreakyCobra wrote: post #271

Earlier quoted context omitted.

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

Indeed, this bug is pretty nasty for the battery. I don't have it though, so my remark was about non-buggy battery usage. Web-based text editors consumes more battery, but the difference is not significant from my point of view.

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

#473

Post by kchoudhu »

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.

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

#474

Post by sqeaky »

pcwalton wrote: post #422
throwaway2048 wrote: post #400

Earlier quoted context omitted.

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.

I have had to use the win32 API within the last year. I left that job, I regret nothing.

As much as I want as few layers between me and the hardware as possible, I would rather have many sane layers like much of the web than 1 insane layer like the win32 API. It doesn't follow good C, C++, std library or other conventions. Many functions have multiple poorly documented modes based on which structs you pass are empty or null pointers. It also just fails often for no reason I can understand, and the distinction between windows application and console is quasi magical and counterproductive.

Posix... Is a blessing by comparison. Every time I need to touch it it take me something like a single hour and I have a function that works reliably and just does what I need. Until we get to X11 and manipulating those windows. Then I just want to punch everything, but at least X11 works once the code is written, even though its inside out and backwards.

Now I just strongly prefer to use a good library to get at OS facilities. Things like SDL, boost or Intel Threading build blocks, etc. They are fast and generally tight enough I can open them and understand down to the hardware when I want.

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

#475

Post by coldtea »

Mister_Snuggles wrote: post #451
nolok wrote: post #55

Earlier quoted context omitted.

> I'm not sure why this implementation is slow I'm guessing the culprit for that is in this part of the bug report: > Zooming into a single frame, we see that while we render only 2 fps, the main thread is performing some work at 60 fps (every 16 ms) As for > why they needed to implement it themselves and not let the OS handle the blinking cursor They're not editing inside a text editor field anymore, they need to bl…

On Win32[0], the blinking caret can be shown anywhere inside a window, not just on a text field. The sample program builds a basic text editor without cheating and using a textbox control. I'm sure other operating systems have this kind of facility - after all, how does the built in text edit control draw its caret? [0] https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...

>On Win32[0], the blinking caret can be shown anywhere inside a window, not just on a text field. (...) I'm sure other operating systems have this kind of facility - after all, how does the built in text edit control draw its caret?

The "built in text edit control" IS a native text field already.

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

#476

Post by coldtea »

tinus_hn wrote: post #52
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…

iTunes has the same issue with its spinner while syncing, it takes about 20% CPU time.

Who said it's the spinner in that case?

After all, it IS syncing at that time, which means it does a lot of stuff.

Whereas the issue here is with the caret shown when the editor is idle.

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

#477

Post by coldtea »

pcwalton wrote: post #458
revelation wrote: post #452

Earlier quoted context omitted.

Yes, that is what I'm saying. They are not porting it because previous solutions have been just as capable.

But they did port it. That's why CSS Grid exists…

Yes, but his point is that for ages it didn't exist. Like, for 2 decades and something, was first tables, then "floats" BS.

And even now it's still not mature and supported in all browsers.

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

#478

Post by mohaine »

Mister_Snuggles wrote: post #435
paulirish wrote: post #244

Earlier quoted context omitted.

Powerful* text editors built on the web stack cannot rely on the OS text caret and have to provide their own. In this case, VSCode is probably using the most reasonable approach to blinking a cursor: a `step` timing-function with a CSS keyframe animation. This tells the browser to only change the opacity every 500ms. Meanwhile, Chrome hasn't yet optimised this completely yet, hence http://crbug.com/361587 . So curren…

> Powerful* text editors built on the web stack cannot rely on the OS text caret and have to provide their own. Is there any reason that Electron couldn't provide an API that would expose the system caret in an OS-agnostic manner? Windows, for example, has an API[0] that can arbitrarily show the caret at a given point in the window. Sounds like something that would be useful to many apps and not get in the way for th…

Probably not easily. Remember this is what java AWT did and it was a complete mess. Write once debug everywhere.

My favorite issues was that on one OS (windows I think) a panel would only be visible if pixel 0,0 was on the screen and nothing was on top of it. The panel could be 99% visible but not be shown at all if the upper left corner was under another panel.

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

#479

Post by ovao »

Kiro wrote: post #364
ovao wrote: post #131

Earlier quoted context omitted.

What native editors have you used?

Primarily Sublime Code, Notepad++, PhpStorm and NetBeans.

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

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

#480

Post by sqeaky »

dom0 wrote: post #404
ballenf wrote: post #181

Earlier quoted context omitted.

On a per-application basis, you are probably correct. But if the additionally abstraction layers allow there to be greater diversity of applications and more tools for more niche cases because development is easier and/or faster, then that is directly immediately beneficial to the end user. Not to mention faster design iteration, implementation of new features etc.

> On a per-application basis, you are probably correct. But if the additionally abstraction layers allow ... Windows 7 boots in approx. 5 seconds to the desktop (if no password is set), and stuff like Word or Visio starts instantaneously . Web applications on the very same computer are a whole different story. Let's just acknowledge that SaaS is not and never was about any kind of benefits for the user or customer, b…

I have never seen word open instantly. When I do it there is always a second or two for teh obnoxious splash screen, then often 10 to 15 seconds waiting for it to do whatever. Notepad++, yeah, that opens nearly instantly.

I mostly use Ubuntu and there Libreoffice still has a stupid splash screen. After that though the amount of time is too small for me to count.

Post reply on HN