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

Post by Mister_Snuggles » Thu, Mar 23, 2017, 7:05 PM UTC

nolok wrote: post #55

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.

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

Post by MichaelGG » Thu, Mar 23, 2017, 7:07 PM UTC

Paradigma11 wrote: post #384

MichaelGG wrote: post #284

Earlier quoted context omitted.

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.

Post by eltoozero » Thu, Mar 23, 2017, 7:07 PM UTC

pcwalton wrote: post #300

coldtea wrote: post #162

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? No, we don't. With Windows API there's no sandbox and extra embedded language overhead (it's still native code like in DOS, and even optimized better, able to use more available memory than DOS would allow, etc.). Oh, and you also got the benefit o…

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

Post by Klathmon » Thu, Mar 23, 2017, 7:10 PM UTC

dang wrote: post #438

Klathmon wrote: post #342

Earlier quoted context omitted.

Can we cut the "holier than thou" pretentious bullshit? Just because someone uses a different language, or solves different problems doesn't make them worse or any less "hardcore" than you. You are right, the average JS developer might not be able to instantly know the details about how to implement a text buffer, because they don't need to do that on a daily basis. You probably don't know the details about how to im…

This breaks the HN guidelines about civility and not calling names in arguments. Please don't respond to a bad comment with an even worse one.

Post by eltoozero » Thu, Mar 23, 2017, 7:11 PM UTC

cr0sh wrote: post #120

onion2k wrote: post #88

Earlier quoted context omitted.

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.

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