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

381–390 of 801 posts

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

#381

Post by smitherfield »

jug wrote: post #359
pyre wrote: post #139

Earlier quoted context omitted.

There is a point to be made here though that is more valid than the argument against moving away from command-line DOS applications to Windows API applications. Moving from text-based to graphical is a much different shift than what we are talking about here. The idea here is that we are creating many abstractions to get the same basic result. I can't rewrite Atom.io for DOS, but I could rewrite Atom.io to use the Wi…

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

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

#382

Post by dheera »

stickfigure wrote: post #240
thechao wrote: post #129

Earlier quoted context omitted.

Except that the abstraction layer for the user has remained the same. The extra abstraction layers you're talking about are invisible to the user... while our GUIs are slower, and our processors faster. It feels like, after 30 years, we should be able to have our GUI cake and eat it, too.

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

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

#383

Post by logicallee »

onion2k wrote: post #88
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.

Google Docs takes a good 2-3 seconds to spin up a UI on my i7. I doubt much of that time is spent building the DOM tree for the UI. Google Docs does a lot more than a simple text editing widget - there's a networked file system, a multi-user collaboration engine, a realtime notification system, etc that all get initialised. Instantiating all that over a network in 2-3 seconds is really fast.

>Instantiating all that over a network in 2-3 seconds is really fast.

I see. In your opinion, do you think Chrome would be even faster if it managed to spin up an entire sandboxed docker container (in case any web site wanted one, to do whatever it wants with), as well as another one with a full Postgresql install (again in case any web site wanted one, to do whatever it wanted with, oh, and also for Chrome's own bookmarks and stuff), yet still launched within a blazing 14 seconds?

Would that be even faster, considering?

Because from where I'm standing, that wuold be 5-7 times slower.

And 3 seconds to start is 2.95 seconds too slow for me to start typing into a URL box, which could appear within 50 ms if it was done right instead of done wrong.

Chrome does things wrong instead of doing things right, and it really is that simple. I'm a human, not a network share. I use software so I can interact with it. It should do the rest on it's own time and as needed.

Loading a bunch of stuff "quickly" does not equal being quick. Google should know better.

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

#384

Post by Paradigma11 »

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.

It takes maybe half a second on my 4 year old Core I5.

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

#386

Post by pcwalton »

dheera wrote: post #373
pcwalton wrote: post #319

Earlier quoted context omitted.

Flexbox is that improvement. If you discount flexbox due to "not [being] used very often", then you can't logically argue for burning down the HTML and CSS stack and replacing it with something else that has zero market share.

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.

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

#387

Post by payonel »

aphextron wrote: post #16

I simply cannot understand why Atom and VSCode are so popular. I get that they are extensible, but is that really worth the slowdown to you? If I need more features than a text editor, I use an actual IDE. Someone just posted some really embarassing benchmark numbers regarding this issue yesterday: https://github.com/jhallen/joes-sandbox/tree/master/editor-p... Note that Atom and VSCode are nearly 10x slower than all…

That benchmark is 7 months old. I just tested the same operations with vscode and did not see any operation take more than 2 seconds. Opening test.xml, scrolling to the end, and closing vscode in <2s. Replace all instances of thing with thang, <2s. VSCode has made significant improvements since last summer when it first was released - that could be part of the reason for these discrepancies.

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

#388

Post by c-smile »

jblow wrote: post #371
c-smile wrote: post #352

In GDI era caret bar ( that's not cursor , sic!) was rendered as by simply inverting pixels (InvertRect() call) inplace in video frame buffer. Very cheap operation that does not require redrawing and run of any other code. With the GPU the only viable option for rendering blinking caret is to redraw the whole window. That's why it takes so much CPU as Chrome uses mostly CPU based rasterizer. But redrawing the whole w…

"With the GPU the only viable option for rendering blinking caret is to redraw the whole window." Sorry, that is plainly false. There is nothing preventing you from treating an offscreen buffer just like any other buffer of non-dirty pixels. Treating the back buffer that way is slightly less conventional but is still just fine.

> There is nothing preventing you from treating an offscreen buffer just like any other buffer of non-dirty pixels.

You need:

1. ability to invert pixels by CSS/JS. No such feature in principle. For many reasons.

2. Even if you will be able to invert those pixels in offscreen bitmap you need to send that window's offscreen bitmap to CPU on each caret blink. You can use tiles - so do partial CPU->GPU data transfer but still.

3. If you use offscreen buffer you are almost always use CPU rasterization. CPU rasterization is O(N) operation, where N is a number of pixels.

On high-dpi monitors (200dpi...300dpi) number of pixels is 4...9 larger than on "standard" 96dpi monitors. And CPU stay roughly the same last 4-6 years. So if you want your app to run on modern hardware - GPU is the only viable option for rendering - forget about offscreen bitmaps and the like.

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

#389

Post by pcwalton »

smitherfield wrote: post #376
pcwalton wrote: post #330

Earlier quoted context omitted.

Precisely. And even Win32, which is being touted in this thread as somehow far superior to the Web stack, was never designed for high DPI apps. It's far worse than the Web stack, with exact pixel hardcoding everywhere. That's why the HiDPI situation on Windows is such an inconsistent mess. Meanwhile, the Web scaled up to HiDPI so seamlessly that most people never even noticed any friction. This is the benefit of the…

Isn't this a false dichotomy? Why not create more modern, declarative native APIs and libraries, or use them where they already exist?

Because it's less effort and more likely to be successful to just improve Web implementations.

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

#390

Post by [deleted] »

Philipp__ wrote: post #14

It just doesn't go in my head that we are building text editors inside a web browser! I get it, there are many good use cases for Electron and it's easy to get started with cross platform support, but why is everybody going crazy about text editors in them? Because you can write plugins in JS? Wouldn't it be better to make native application, especially for code editors, where developers spend most of their time, whe…

[deleted]
Post reply on HN