Live data from Hacker News

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

github.com

521–530 of 801 posts

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

#521
post #405

Earlier quoted context omitted.

None of the 3 things you said are true. I recommend you get some experience in rendering before you mislead people too much with these kinds of comments. In reality the problem is trivial, you set up a scissor rect (or explicitly mask the pixels in your shader) and then render only stuff overlapping that square. You don't need to invert the pixels for it to be fast; you can render an arbitrarily nice cursor effect.

I am not sure I understand why do you need clipping at all to render rectangular caret bar (note: cursor is a different entity in UI professional jargon). What exactly you want to be clipped out?

I am assuming that your caret bar may be overlapping text in some way, or that there is a background bitmap that you might be alpha-blending against, etc. Basically I don't want to make an assumption that might break if the UI gets nicer. The case of a strictly opaque strictly rectangular non-antialiased non-smoothly-moving bar does not seem very interesting or nice-looking.

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

#522
post #512

OH GOD NO Adding ANOTHER interpreted language to the pile? Jeeze you guys are crazy. Just STFU and learn C/Go/Java Does ANYONE in NodeJS world care about efficiency? Or does this "plebian" (ew! hacking is not plebian!) hackability trump all other concerns?

Please don't. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newswelcome.html We detached this subthread from https://news.ycombinator.com/item?id=13940554 and marked it off-topic.

There might be an insult or two thrown around but detaching the thread removes necessary context. I do not think that this was the appropriate course of moderation.

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

#523

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…

Minimizing the installation window would prevent the paint event and your installation would finish quickly...

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

#524
post #436

> Because you can write plugins in JS? Yeah, kind of. Sadly most developers have neither formal nor self-taught education about compiled programming languages and/or desktop development. They're only familiar with web-related programming, so if you only have a hammer, everything looks like a nail. Being a hardcore real-time desktop developer during the mornings and a freelance web developer in the afternoons, I hones…

Please don't post putdowns of entire classes of people. It's unsubstantive and leads to flamewars, as demonstrated by the below. We detached this subthread from https://news.ycombinator.com/item?id=13940405 and marked it off-topic.

Putdowns? What putdowns exactly? According to the StackOverflow 2016 Developer Survey [1], almost 70% of the developers are self-taught, and also according to that survey, JavaScript is the most popular language, more than twice as much as C++. That pretty much covers my first paragraph.

As for the second, I'm confident about the average JavaScripter not being able to tackle C++. If you find that an insult, that's ok, but it's the reality. Try explaining custom memory allocation algorithms to the vast majority of script kiddies that call themselves "front-end developers" just because they use jQuery daily.

[1] http://stackoverflow.com/insights/survey/2016

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

#526

Earlier quoted context omitted.

HTML and CSS are a bad fit for rendering heavy graphical interfaces because they fundamentally follow a document flow rather than grid-based layouts. Flexbox and css-grid are helping some in this area, but they are not used very often. (not to say that HTML and CSS aren't useful, but they are far from the idea means of rendering a UI). HTML does work fine when you use it for mostly document focused work, and I enjoy…

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.

My point wasn't so much that Flexbox isn't that improvement, but that I haven't yet had a chance to fully learn it, and I suspect that a lot of front-end developers are in a similar space. I plan on rectifying that soon, but it is yet another thing to add atop the large number of other things that comprise understanding modern web browsers.

I'm not saying that we should burn the HTML and CSS stack. It has served the web very well and will continue to do so, but until the last few years, it's been a document focused stack that's been twisted into doing app development, and in some sense, it still is.

HTML and CSS are not the best tool for heavy GUI development, a la Photoshop, Visual Studio (not VS Code) or other large GUI intensive things. Most web apps have yet to replicate the combination of features and/or performance of those types native applications. Flexbox is an improvement there that helps with layout, but that doesn't change the fact that we are working with the DOM under the hood, with all of its various quirks and performance issues. (Not to say other GUI frameworks/APIs are perfect, or necessarily better. Some of them just allow you to optimize a little closer to the metal).

One can point out that large GUI tools like Photoshop aren't being created as much these days, outside of AAA game dev, CAD, or the like, or that many large GUI's use web views to help display documents, a la Steam.

I sincerely hope that Servo's "Web Browsers are essentially AAA game engines" approach catches on.

I'd be interested to see how an event-based html5 canvas GUI library would compare to DOM.

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

#527
post #41

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…

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.

Am I the only one around here who prefers a nonblinking cursor. That and key repeat rate are my first setting on any new install.

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

#528
post #253

Earlier quoted context omitted.

The abstraction layer has only remained the same visually, and only for a loose definition of "visually." In the "good old days" the user interface was 640px x 480px (original VGA[1], skipping past the original MDA, CGA, and Hercules graphics cards[2] since they predated "modern" GUIs). Then it was expanded to 800x600, etc. The programs of those days were hard-coded to the graphics adapter resolution. If a program di…

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…

Win32 was designed around DPI-independence from day one. That's why things like GetSystemMetrics exist. Unfortunately, the app developers chose not to use them.

GDI was originally designed to run on printers as well as screens, where the DPI values are completely different.

The declarative model of CSS has nothing to do with it. You can specify pixel values in CSS if you like.

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

#529
post #414

Earlier quoted context omitted.

There was a big new overhead -- in DOS you could write directly to video memory, and control the graphics cards registers directly. In windows you had to go through libraries. Until DirectX came along, it was basically impossible to write even reasonable performance animations in windows, hence the lack of games in windows 2 and 3.

That is not true, before DirectX there was WinG and there were quite a few good games done in WinG. The lack of games was mostly due to reluctance of game developers to abandon Assembly and using directly PC hardware, specially because C and C++ compilers were "too slow".

WinG didn't come around until 1994 though. If you wanted to ship a game in 1990, you had a choice of using GDI or using MS-DOS.

And the "assembly" argument doesn't make any sense. You can program Windows games in assembly if you want.

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

#530

Earlier quoted context omitted.

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

> the old stuff worked just fine > we don't need the new stuff > how about we throw both away to shut everyone up, would that make either side happy?

How about: Take what we learn from new development so that we can improve the older, lower-level stuff, and strip away some unnecessary levels of abstraction?
Post reply on HN