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

631–640 of 801 posts

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

#631

Post by trishume »

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…

This argument looks like you and pcwalton are arguing about different definitions of "immediate mode API". I think both of you agree with each other on object-level propositions.

pcwalton seems to be presuming that part of the contract of an "immediate mode API" is like old-school ones it actually immediately draws to the frame buffer by the end of the call.

Whereas you are talking about modern "immediate mode API"s where the calls just add things to an internal data structure that is all drawn at once, avoiding unnecessary shader switches etc. IIRC this is how Conrod (Rust's imgui library) and https://github.com/ocornut/imgui work, although with varying levels of caching.

One point to make about retained mode GUIs is I remember reading an argument that immediate mode is great for visually simple UIs, such as those in video games, but isn't as good for larger scale graphical applications and custom widgets. For example when rendering a large text box, list or table you don't want to have to recalculate the layout every frame so you need some data structure that sticks around between frames specific to the widget type, so that's what retained mode APIs like Qt do for their widgets.

Sure you can do the calculations yourself for exactly which rows of a table are currently in view and render those and the scrollbar with an immediate mode API, but the promise of toolkits like Qt is that you don't have to write calculations and data structures for every table.

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

#632

Post by ashark »

mercer wrote: post #220
dheera wrote: post #186

Earlier quoted context omitted.

> there's a networked file system > a multi-user collaboration engine > a realtime notification system None of these apply to a new, unshared document. Those subsystems can be loaded slowly over the following 10 seconds, that's fine. Is it such a hard thing to ask to make the UI responsive within 0.1 s? Like, be able to type stuff and have it appear on the screen without delay? It's so bad that I often use the basic…

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.

Use the basic HTML version. It's worth the loss of a couple features from regular gmail or inbox for a much snappier UI (even with it fetching full new pages from the server all the time!)

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

#633

Post by jodrellblank »

logicallee wrote: post #333

You know how there's like, hard real time embedded programming where if you don't hit your realtime deadline every time without exception forever, your engine explodes or something? Well, apparently the web is built on whatever the opposite of that style of programming is.

whatever the opposite of that style of programming is.

Is it "fun"? I bet it's fun.

Or easy. Or convenient. Or low effort. Or relaxing. Or accessible. Or cheap. Or quick.

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

#634

Post by ashark »

Wofiel wrote: post #430
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.

I've found this so often, I have a dual Xeon and 16GB of RAM and a calculator of all things taking more than a second is unacceptable. I got a popup inside the calculator asking for feedback about it once with an inbuilt form and submission. I can only assume it has toooooons of hidden away cruft that does everything but assist in calculating things.

I can see it now.

Manager: All apps have to use this feedback framework now, no exceptions. Getting feedback is super important so we can be more Agile!

Dev: ok... uh, but this is 40x the size of all of calc.exe. Plus it's just a calculator and we've refined it for years so it's pretty good already. Isn't that kinda nuts?

Manager: metrics! Feedback! Agile! Just do it!

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

#635

Post by jodrellblank »

tomc1985 wrote: post #519
joshuamorton wrote: post #491

Earlier quoted context omitted.

that was a typo. "not-interpreted" was my intended statement. And I'd love for you to show me a python variant that is compiled in the same way that C is compiled. The closest is nuitka, which...isn't.

cpython? I know the regular python-2.7 installer in debian does binary compilation, producing little *.pyc files for everything

They are binary files, but they aren't "compiled binaries in the same way that C is compiled", they are intermediate Python byte-code files and they still need the CPython runtime to interpret them.

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

#636

Post by jodrellblank »

drzaiusapelord wrote: post #30

>A workaround for folks who are similarly obsessed about battery life That's odd wording. Obsessed because I don't want to waste energy, which leads directly to pollution? Or don't want a short battery life on my laptop? Power savings shouldn't be seen as irrelevant geekery. 13% is half the capacity of a single core in a four core processor. My 5 year old 2500k peaks at 120 watts. So 15 watts to render a cursor? Micr…

There's nowhere saying this keeps the processor at max power state, so not 15 watts to render a cursor.

Your comment is going to be hosted on news.ycombinator.com, replicated through CloudFlare's CDNs, downloaded over and over and spidered by every search engine on the planet, indexed, replicated through all of their worldwide datacenters, backed up onto tape, copied into training sets, and a contender for the result set of every single internet search on every search engine for the rest of eternity or as long as people search with words.

How much energy will that take, all in?

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

#637

Post by symlinkk »

dom0 wrote: post #408
symlinkk wrote: post #368

Earlier quoted context omitted.

Qt isn't native. They're drawing their own widgets that look close to native - that's why you can theme Qt apps.

Factually incorrect, since Qt uses native widgets when possible. Applying Qt stylesheets usually disables use of the operating system's styling engine, i.e. only then Qt starts drawing the widgets by itself. Widgets that are not part of the native widget assortment are drawn by Qt.

Then what is this blog post about? https://blog.qt.io/blog/2017/02/06/native-look-feel/

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

#638

Post by userbinator »

coldtea wrote: post #484
pcwalton wrote: post #300

Earlier quoted context omitted.

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

> Completely disagree. Charles Petzold's HELLO.C is hundreds of lines of code. Hello World on the Web is, well, "Hello world!". It's actually 87 lines of code, with a disclaimer comment, ample empty lines, a callback to play a wav when clicked, and an error message for when it's not run on NT. So, like 30-50 lines of actual Hello World necessary code. And that includes the starting up boilerplate. That's about as rel…

It's actually 87 lines of code, with a disclaimer comment, ample empty lines, a callback to play a wav when clicked, and an error message for when it's not run on NT. So, like 30-50 lines of actual Hello World necessary code. And that includes the starting up boilerplate.

Petzold's Hello World is far more than what I'd consider a Hello World in Win32, because in addition to what you noted, it also creates a "full" window with all the associated complexity of managing its drawing yourself. A more suitable Win32 Hello World is not that much more complex than the traditional C one:

    #include 
    #include 

    int main() {
        MessageBox(0, "Hello World!", "Hello World!", MB_OK);
    }
From there, one can progress onto "dialog-based applications", where the bulk of the layout is declarative (in the resource file) and the C part is two functions, a callback for messages and a main() which just calls DialogBoxParam(). No WM_PAINT handling is necessary for those. A "full window" application is actually not necessary for many use cases. I've been working with Win32 for over a decade and a half and written at least a dozen little apps for various things, but the vast majority of them are not "full window" apps.

In other words, I'd say Petzold was at least partially responsible for giving the impression that Win32 is impossibly complex even to start with. Fortunately others have come up with better introductions like http://www.winprog.org/tutorial/ or even https://win32assembly.programminghorizon.com/tutorials.html since then, but it seems that the damage has already been done and a whole generation of programmers have gotten the "Win32 is hard" notion embedded into their minds.

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

#639

Post by redial »

jodrellblank wrote: post #633
logicallee wrote: post #333

You know how there's like, hard real time embedded programming where if you don't hit your realtime deadline every time without exception forever, your engine explodes or something? Well, apparently the web is built on whatever the opposite of that style of programming is.

whatever the opposite of that style of programming is. Is it "fun"? I bet it's fun. Or easy. Or convenient. Or low effort. Or relaxing. Or accessible. Or cheap. Or quick.

Or stubborn.

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

#640

Post by braveo »

klibertp wrote: post #574
braveo wrote: post #200

Earlier quoted context omitted.

That's been my experience as well, although that's still too slow for my tastes as a vim user. But I definitely don't ever recall it being 8 seconds, that feels like either an exaggeration or someone working on a potato.

> that feels like either an exaggeration or someone working on a potato. Haha, no. It depends on what you use Emacs for. Remember the old joke about Emacs being a great OS? The reality is that Emacs is a great computing environment for almost anything that deals with text and even for some completely unrelated things. If you want a cross-platform GUI then Emacs Lisp may be one of the choices available. This caused "p…

fair enough, I've never been able to stay with emacs long enough to collect the plugins.

The 1-2 second startup was slow enough that I couldn't even stay with the Emacs evil mode.

Post reply on HN