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

531–540 of 801 posts

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

#531

Post by problems »

KirinDave wrote: post #492
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.

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.

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

#532

Post by CodeWriter23 »

yeukhon wrote: post #444
CodeWriter23 wrote: post #316

Why hasn't someone thought of implementing a blinking cursor in hardware, like we did in the early 80's?

How would that work in reality?

Back in the day you'd write a value into hardware register and the video hardware would draw the cursor at the location designated by the written value. The hardware that was generating the signal to drive the beam would AND the VRAM contents with the register and XOR that result with a clock that pulsed at the blink rate. Voila, blinking cursor.

In this day and age, I imagine you write some code that runs in the GPU off a timer interrupt that pumps the texture of a cursor to a location on screen based on a value stored in some scratch RAM. Exposing that interface to some JavaScript running an editor in a browser is left as an exercise for the jackasses who have taken what we would call a SuperComputer back in the day and turned it into wheezing desk heater with a stuttering UI.

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

#533

Post by jbtule »

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…

You know what would be fast for display updating, ncurses. I wonder why they didn't use that? If only we had an ncurses based text editor.

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

#534

Post by zbuf »

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…

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 again, eh folks?

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

#535

Post by nissimk »

eltoozero wrote: post #459
cr0sh wrote: post #120

Earlier quoted context omitted.

...a whole 2-3 seconds! Sometimes I think that comments like these arise out of not having experienced text-only rendering at 300 baud... I know that's a generalization, and most likely unfair - but damn, today's phones, to this old man, are pocket super-computers (for that matter from my vantage point, an Arduino is a wonder, and a RasPi is utterly amazing)!

I can't remember the stand-up routine, but the punchline applies: "10secs! I was supposed to be at work 15 seconds ago!"

thanks.

https://www.youtube.com/watch?v=_HozBKiWGsQ

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

#536

Post by dbbolton »

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…

Don't forget to install the plugin that actually allows you to run a web browser inside your web browser-based editor:

https://atom.io/packages/browser-plus

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

#537

Post by rleigh »

jblow wrote: post #502
pcwalton wrote: post #426

Earlier quoted context omitted.

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…

Ehh, game engines are not really retained-mode in the way you mean. There isn't usually a cordoned-off piece of state that represents visuals only. Rather, much of that state is produced each frame from the mixture of state that serves all purposes (collision detection, game event logic, etc). "What happens if you try to present an immediate mode API for UIs is the status quo with APIs like Skia-GL." I don't know wha…

Motif and Xlib use expose events to handle drawing. Doesn't imply retained mode drawing; you could use either in the handler.

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

#538

Post by gmfawcett »

lispm wrote: post #366
gmfawcett wrote: post #325

Earlier quoted context omitted.

I should be more clear. I don't think that just because Emacs contains an Elisp interpreter, we should call it a "non-native" application -- even if Elisp is integral to Emacs' operation. If forced, I would say that Emacs-the-platform is native, and Emacs the system of Editor MACroS is not, since the macros run on the Emacs platform. But it seems kind of pedantic.

The Lisp code is not natively executed. Some features like memory management (garbage collection) are layered on top of the OS. The UI is not 'native' - it's based on a portable substrate written in C/Lisp, which works both on WIMP and terminal systems. The user interaction is not native (commands, buffers, undo, preference dialogs, window/frames, ...). etc.etc.

I never said the Lisp code was natively executed. I'm not sure where you got that idea.

Let's just agree to disagree. We are talking past each other at this point. Best regards!

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

#539

Post by Someone »

paulirish wrote: post #244
Touche wrote: post #41

Earlier quoted context omitted.

I think I don't understand the issue well enough. This looks like a standard blinking cursor to me. Users expect a blinking cursor in an editable text field. I'm not sure why this implementation is slow or why they needed to implement it themselves and not let the OS handle the blinking cursor. I'm guessing there must be some reason.

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…

"So currently, Chrome is doing the full rendering lifecycle (style, paint, layers) every 16ms when it should be only doing that work at a 500ms interval"

Only? It shouldn't be necessary to layout the entire window to redraw a cursor.

Also, if it did update every 500ms:

- it still would use about half a percent of CPU. On a machine whose CPU easily is >200 times as fast as those powering the first GUIs (and those _could_ blink the caret at less than 100% CPU) and that has a powerful GPU, that's bad (yes, those old-hat systems had far fewer pixels to update, but that's not a good excuse)

- implementing smoother blinking (rendering various shades of gray in-between) would mean going back to 13% CPU.

I would try and hack this by layering an empty textfield on top of the content, just to get a blinking caret. Or is it too hard to make that the right size and position it correctly?

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

#540

Post by sedachv »

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

Abstraction is about coming up with general designs from many specific implementations. You can layer abstractions but layering is not fundamental to abstractions.

Just because a design introduces extra indirection into a system does not mean that the design is providing any abstraction.

Likewise just because a design changes from one implementation to another does not mean anything has been abstracted.

Your example of moving from DOS to Windows is really good for illustrating this. DOS had almost no hardware abstraction support, you had to include drivers for a lot of hardware into your application. Moving from DOS to Windows 3.1 only provided abstractions over the video drivers, for example when it came to network cards you still had to use DOS drivers.

Moving a text editor from DOS to Windows does not provide you with any abstractions for things like the cursor. It is only changing the API for the sake of having your text editor run on a different platform.

Guess what? This is the same with trying to get your cursor and text rendering working on a web browser. There is absolutely no abstraction here, you are just changing your code to work with the very awkward DOM API.

Post reply on HN