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

371–380 of 801 posts

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

#371

Post by jblow »

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.

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

#372

Post by mercer »

criddell wrote: post #317
mercer wrote: post #220

Earlier quoted context omitted.

Over the past year or two Gmail has gotten really slow. I'm not sure what happened, because there are no new features I can think of that would cause this. It's gotten so bad that I'm considering moving to another provider or using a good old email app again.

I've noticed that too! Do you use Inbox? I do and I was thinking about going back to the classic interface to see if it's faster.

Oh, I tried Inbox but Gmail was nice and fast compared to that pos.

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

#373

Post by dheera »

pcwalton wrote: post #319
yumaikas wrote: post #291

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.

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 you center a paragraph of text vertically in a div? A: Nested div hell.

I'd say FlexBox is pretty inadequate. Why can't we have things like:

    #my-video {width:80%;height:calc(width*2/3);}

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

#374

Post by phkahler »

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…

>> Powerful* text editors built on the web stack cannot rely on the OS text caret and have to provide their own.

Powerful features do not require retarded implementations.

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

#375

Post by jes5199 »

ConceptJunkie wrote: post #345
watty wrote: post #297

Earlier quoted context omitted.

It just doesn't go in my head how so many people have trouble understanding why things like VSCode or Atom are popular. They're sexy, they are powerful (extensions for everything), portable, and extremely easy to extend thanks to Javascript being pervasive. I don't know for certain but I'd also assume writing an Electron app is easier than writing a similar app in a lower level language. Is it really that hard to gra…

I've played around with VSCode and what it can do seems impressive, but I want to do one simple thing. I want to make the background black. Every dark theme I can find makes the background dark gray, not black. I actually looked into what it would take to make a new color theme and I simply don't understand all the steps, and definitely don't want to deal with the hassle. It very quickly goes off into the weeds of Te…

I don't know about VSCode, but in Atom you'd just write one line of CSS

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

#376

Post by smitherfield »

pcwalton wrote: post #330
gvb wrote: 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…

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

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

#377

Post by digi_owl »

forgotpwtomain wrote: post #326
digi_owl wrote: post #250

Earlier quoted context omitted.

Some time ago HN linked to a blog from a Norwegian tasked with mailing 3.5" floppies to doctors. This because the doctors insisted on using a DOS based patient journal, as they could operate it completely by keyboard while maintaining a conversation with the patient. I speculate that one reason for this is that DOS allowed each program to have full keyboard access, while Windows and other GUI has to reserve certain k…

Do you happen to have the link to this blog handy? I'd be interested in reading it.

You got me digging, so here is the HN discussion about it.

https://news.ycombinator.com/item?id=10287889

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

#378

Post by kibwen »

Not to defend Electron (I use neither VSCode nor Atom), but meanwhile I'm over here watching the JVM consume a constant 10% of my CPU thanks to having a single 60-line file open in the official Arduino editor (which isn't even an IDE, it's a glorified GUI for compiler flags with a built-in syntax highlighter).

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

#380

Post by [deleted] »

ConceptJunkie wrote: post #353
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…

Perhaps, but the grandparent has a point. Javascript is the hammer that's turned every kind of software development into a nail, and it simply isn't so.

[deleted]
Post reply on HN