37 ms·

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

899 points by Kristine1975 10y ago

okket 10y ago
TL;DR: It seems to be a problem in Chromium, the relevant CSS (one second change) results in a 60hz animation cycle. Workaround: "editor.cursorBlinking": "solid"
- johnhattan 10y ago
  You think this is gonna be fixed in Chromium, fixed in VSCode, or working-as-designed?
  - okket 10y ago
    Issues/bugs are filed, see https://github.com/Microsoft/vscode/issues/22900#issuecomment-288529120 https://github.com/Microsoft/vscode/issues/22900#issuecommen...
- revelation 10y ago
  Okay, but checking at 60 hz if an animation needs to be updated is not relevant work. In no universe should that cause 13% processor load. Sure maybe you can get smarter and realize that all animations run at 2 hz and then also only check at 2 hz, but it seems the root problem here is an entirely different one.
- ygra 10y ago
  Interesting, considering that CSS animations were supposed to be much better than JS animations in that regard. I guess a simple setInterval would actually perform better here.
  - ralfn 10y ago
    CSS animations and raw JS animations perform equally well. JS had a bad reputation for animation only because the common libraries back then (jquery, mootools) had absolute horrible incompetent implementations. This also has nothing to do with the blinking interval. A setInterval would simply not do the same. The CSS animation is fading its opacity at 60 fps not toggling it. Doing the same with a setInterval(.., 1000/60) will use the same amount of CPU. As any introductory tutorial about css animations explains: They interpolate between the percentages you are not providing! So thats a DOM update every 12ms. The reason its smooth is because opacity (like transform) does not trigger a relayout. Finally, whatever is triggering relayouts is not the opacity change, but some other obviously badly written code that is continously triggered on requestAnimationFrame and is touching the DOM even though, zero dom writes should be taking place on idle. (And zero dom reads always! Since reading from the DOM triggers synchronisation between the rendering thread and the js thread)
    - mastax 10y ago
      > The CSS animation is fading its opacity at 60 fps not toggling it. Most of the cursor styles have some sort of animation, but the "blink" style is just an on-off blink with no fade. Chrome updates every animation at 60hz, even step animations like these. This is an acknowledged issue in the Chrome bug tracker as linked in the issue.
- artursapek 10y ago
  I recently discovered the same issue in a webapp I develop... a simple CSS animation for a "loading" spinner was pegging the CPU. Using steps(n) with a low number basically resolves the issue. https://css-tricks.com/snippets/css/keyframe-animation-syntax/#article-header-id-6 https://css-tricks.com/snippets/css/keyframe-animation-synta... Kind of ridiculous that it's so easy to make this mistake.
  - gigatexal 10y ago
    With great power (flexibility of JavaScript) comes great responsibility.
davidascher 10y ago
Reminds me of this ancient Firefox bug about the performance cost of the throbber: https://bugzilla.mozilla.org/show_bug.cgi?id=437829 https://bugzilla.mozilla.org/show_bug.cgi?id=437829
adamnemecek 10y ago
...21st century desktop application development ladies and gentlemen (not that I'm proposing anything constructive).
- analognoise 10y ago
  Throw it in the bin and return to the old ways, but with modern testing, source control, and static analysis?
Mahn 10y ago
Sounds like this can be fixed by moving away from animating opacity to something more rudimentary like flipping the display property in JS. CSS3 animations from my experience are a bit taxing in general, and something you want to use only in small bursts, not constantly running in the background.
- SippinLean 10y ago
  That would, but right now the cursor fades in and out, it doesn't "blink" exactly, so this suggestion is not a 1:1 replacement. Sounds like they need to optimize their CSS animations in general.
abrkn 10y ago
I recently switched from Atom to VS Code and have noticed a considerable reduction in lag, especially when using CMD+D and searching through project files.
- lotsoflumens 10y ago
  Same here - the lag with just doing simple things in Atom, like moving the cursor, became too much. Since I made the switch I've found VS Code to be quite nice. I miss having Hydrogen available but I can always run jupyter notebook if I need something like that.
thecpphorse 10y ago
Google Docs has the exact same behavior and has for years. I can hear my laptop's CPU whining when the cursor fades in and out.
mschaef 10y ago
This reminds me that as part of the Windows95 development effort, Microsoft disabled per-second updates of the taskbar clock to improve performance. Raymond Chen wrote a bit on it back in 2003: https://blogs.msdn.microsoft.com/oldnewthing/20031010-00/?p=42203 https://blogs.msdn.microsoft.com/oldnewthing/20031010-00/?p=...
- nihonium 10y ago
  On the other hand, iPhone's "Clock" app has an icon that shows the correct time with a super smooth seconds indicator. Which doesn't drain the battery.
  - voxic11 10y ago
    How fast does it run on 1995 hardware though?
    - jbmorgado 10y ago
      Pretty sure any sane software implementation of a simple seconds pointer would easily update faster than 1 Hz while using little to negligible CPU time in a Desktop processor from the 90's and onwards.
      - mschaef 10y ago
        The Windows 1.0 clock (1988) had a 1Hz second sweep hand that ran on a 4.77MHz 8088. It's really just a couple clipped line segments each second. http://variableghz.com/wp-content/uploads/2012/12/windows-1.0-clock-app.jpg http://variableghz.com/wp-content/uploads/2012/12/windows-1....
        jbmorgado 10y ago
        Yes, that was the point I was making. This is something computationally trivial as long as the code is written appropriately.
plg 10y ago
carbon footprint
- betaby 10y ago
  Yes. We quickly forget what those CPU cycles and abundant of RAM consumes electricity => heating the planet.
  - deleted 10y ago
    [deleted]
  - valarauca1 10y ago
    The real issue is cooling the universe and accelerating us to the inevitabile heat death :(
    - rikkus 10y ago
      Quick, produce more heat!
- GoToRO 10y ago
  Yeah. Somebody is putting coal on a fire so I can have a cursor blink on my screen. Makes you think :)
Philipp__ 10y ago
It just doesn't go in my head that we are building text editors inside a web browser! I get it, there are many good use cases for Electron and it's easy to get started with cross platform support, but why is everybody going crazy about text editors in them? Because you can write plugins in JS? Wouldn't it be better to make native application, especially for code editors, where developers spend most of their time, where every noticeable lag and glitches are not appreciated. Edit: Many people here think that I am attacking this web based kind of technology, which I am not, and sorry for not being clear enough, but why chose something so high up the stack for dev tool? Edit2: For non-believers in nested comments, look -> https://github.com/jhallen/joes-sandbox/tree/master/editor-perf https://github.com/jhallen/joes-sandbox/tree/master/editor-p...
- jablan 10y ago
  I believe making native application for the three platforms would be considerably more effort.
- brilliantcode 10y ago
  well if you've ever built a cross platform native desktop application, you will appreciate Electron. Java Swing. Never again. edit: Do people downvoting even know what it's like building cross platform desktop applications using Java Swing? It's fucking awful, and that's a fact. Even the end result UI design look & feel is butt ugly. Sure you can spice things up with JavaFX but why? Do you not realize how masochistic it was back then vs now with thin web browser clients? Can't believe people are still thumping Java Swing in 2017.
  - krzyk 10y ago
    Why? With JavaFX where you can customize it using CSS it looks nice, and you don't need to use a scripting language to do it.
    - brilliantcode 10y ago
      Why use JavaFX when you can change the CSS in a web app which is indistinguishable? Here's a easy way to get a job done but people refuse to do it because of philosophical/ideological indoctrination. ex. the world is made of objects therefore our languages and how we build software should now mirror it.
aphextron 10y ago
I simply cannot understand why Atom and VSCode are so popular. I get that they are extensible, but is that really worth the slowdown to you? If I need more features than a text editor, I use an actual IDE. Someone just posted some really embarassing benchmark numbers regarding this issue yesterday: https://github.com/jhallen/joes-sandbox/tree/master/editor-perf https://github.com/jhallen/joes-sandbox/tree/master/editor-p... Note that Atom and VSCode are nearly 10x slower than all the other competition, as well as simply crashing for many of the tests. To be fair, I do think Electron based desktop apps have their niche. Spotify is a perfect example. But they have no place in text editing.
- swalsh 10y ago
  It's not slow to me, I find my computer uses far less resources than say one of the million JetBrain IDE's. Combined with a bunch of useful plugins, it's pretty wonderful.
  - sbarre 10y ago
    You're comparing a text editor to an IDE. If you are able to do your work with a text editor, maybe you didn't need an IDE in the first place. IDEs are definitely slower than text editors, but they have their benefits that comes with their tradeoffs (like most things).
    - swalsh 10y ago
      vscode kind of walks a thin line between IDE and text editor. It has an integrated debugger, intellisense, linting, and plugins to do everything you'd expect from an IDE.
- tommoor 10y ago
  The benchmarks make it look bad but to be honest aren't that relevant for day-to-day use. I can't remember the last time I saw performance issues in Atom and the plugin infrastructure massively outweighs the occasional possible issue
artursapek 10y ago
I'm reminded of this classic: https://github.com/npm/npm/issues/11283 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 apply to VS Code's cursor.
- Touche 10y ago
  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.
  - nolok 10y ago
    > 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 blink on html. I guess they're not using a deprecated <blink> tag is because it's not customizable in any way.
    - kibwen 10y ago
      I don't believe that any modern browser still supports the blink tag; IIRC Firefox was the last to get rid of it, a year or two ago. You can hack it up in CSS, though.
      - ethbro 10y ago
        Truly, the web has come full circle.
drzaiusapelord 10y ago
>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? Microsoft needs to stop it with these terrible levels of QC. Its inexcusable.
- StyloBill 10y ago
  It's a Chromium problem, maybe you should read the Github issue before commenting.
  - big_paps 10y ago
    Still its one of the most interesting posts. x Joules per blink
    - StyloBill 10y ago
      The maths may be interesting, the rant is definitively not.
- fao_ 10y ago
  > Power savings shouldn't be seen as irrelevant geekery. It seems that these days anything that a developer doesn't care about is seen as "irrelevant geekery".
- jodrellblank 10y ago
  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?
mmarks 10y ago
13% cpu usage at the lowest c-state is a also very different than 13% at an elevated c-states. I've recently spent a lot of time analyzing c-states/p-states and the power mgmt modes of the GPU. After learning more about the complexity behind the clocks, bus speeds, etc. underlying each state, whenever I hear someone quote a utilization number of a minor workload, I want to know at what power state. Not to take away but the author's point, just an aside that utilization numbers can be a lot more complicated when there are dozens of energy states and the utilization might be utilization at a particular state rather than utilization at maximum power
- aarongolliver 10y ago
  You mean p-states in your first sentence, right? Anything but c0 represents different levels of 'retiring no instructions' (totally idle). The rest of your comment seems accurate though.
  - mmarks 10y ago
    You're correct that I just meant a lower power state. The author mentioned blinking cursor, so it reminded me of graphics issues. A more efficient CPU state has the possibility of slowing an app due to CPU-GPU sync points. A blocking CPU in an energy efficient state can reawaken slower from GPU done notifications, so FPS is lower. So both c-state and p-states can affect performance. General point was just utilization may not be utilization at max power. I've worked on problems where utilization was 15% at lower power and it was a problem. But to compare different workloads, it'd be < 1% at max power.
- rasz 10y ago
  even the best case scenario is 13% of ~900MHz, 100MHz to blink 20 pixels.
- gpderetta 10y ago
  That's actually even worse: it will prevent the cpu to enter deep sleep states and save more power. A while ago I was trying to minimize the power usage of my laptop (yeah, slow day) to maximize my battery time. Armed with powertop, I removed any undesired process until I was left with an otherwise idle emacs (less than 1<% cpu) as the last major source of wakeups. Sure enough, disabling the blinking cursor brought that down to nothing, allowing the cpu to stay into deep sleep state much longer.
onli 10y ago
Because it hasn't been mentioned yet, as far as I could see: Blinking cursors are horrible and should never exist, it resembles torture. http://www.jurta.org/en/prog/noblink http://www.jurta.org/en/prog/noblink is an extensive list with ways to deactivate it in various programs. Try it out, you will feel the difference.
- juandazapata 10y ago
  I don't like XXX, so it shouldn't exist it's a great argument.
  - onli 10y ago
    No, of course not. It wasn't supposed to be the argument. Are you really interested in the background? I will just assume so, this is HN after all. Our brain has some special recognition for specific things. A collection of those things are bundled under Gestalt psychology. There are also a number of things that make something pop out. Now, movement triggers the pop out effect, it is one of those things that we notice immediately. What that means in practice is that a blinking cursor in an otherwise plain image will be noticed immediately, and it takes conscious effort to ignore it. That is a strain on your mental capacities, and highly unnerving, even if you are not completely aware of what it is that annoys you. Parts of this is what motivates those specialized writer editors, that remove everything apart from pure trext to make it as easy as possible to focus on the task at hand. Blinking cursors, and this is what the jurta page mentions, also resemble the chinese waterdrop torture. I think that was meant a bit tongue in cheek, but is actually not wrong. It comes again and again and again and again ..., and it not immediately controllable. Add to that the useless resource usage like in this bug and yes, I stand to that and am serious about it: Blinking cursors are a very bad habit that should just die out. And developers that actively implement it without making it deactivable should ask themselves what they are doing - I had that with Sharelatex, a platform which I otherwise like a lot.
- rastapasta42 10y ago
  Personally I like the blinking cursor in vim and I don't think dripping water is a good comparison. Without the blinking I lose the file location and have to move it around with "hjkl" so I can find it again.
ChuckMcM 10y ago
I love the irony of simulating an XOR gate from a piece of hardware (a serial terminal) with a billion gates in a processor which renders a square with an alpha blend function. Sort of like using a 787 to sit on the runway, and run its engines to blow a windmill to crank a butter churn :-).
- dahart 10y ago
  That's a fun analogy, made me laugh. :) I see this literally everywhere though, the article at hand is only a slightly better example than almost everything we do. Browsers consume gigabytes of memory to render a few basic web pages. We use high level scripting languages with tons of dynamic memory inside containers that are running on VMs to run all our cloud infrastructure. If we had the time, these things could be multiple orders of magnitude faster and smaller. It just isn't worth our time... :P Another fun example of this I ran into recently is the controllers for brushless drone propellers. The hobby motors you buy for $20 usually have a 1Mhz 8-bit CPU running Electronic speed control, literally shrink-wrapped inside the wires. Every single prop. Think about that, a million instructions per second running, only to make something spin. (To be fair, the CPUs are under-utilized, but still, it reminds me of churning butter with a jetplane.) The main difference, of course, is that cpu time & memory are close to free, and 787's are super expensive. Maybe if 787's were free, we'd use 'em often to churn butter... ;)
  - eeZah7Ux 10y ago
    > cpu time & memory are close to free Not for 3 billion people. Also energy is not free at all.
    - dahart 10y ago
      Right yes, I know, and it's a great point. Global economics and third world access to computing & the internet are in a completely different time zone from I was talking about. But you're right, and on the global scale, we may actually be doing the equivalent of churning butter with jets. I totally wouldn't be surprised if the sum total energy expenditure on all computers in the world was greater than on all the aircraft in the world... and we are most definitely wasting the vast majority of the energy we use on computation. Still, in my defense, I said close to free, and compared to the cost of a 787, cpu time & memory are closer to free than jets, no matter who we're talking about, right?
excalibur 10y ago
Lotus Notes FTW
ohitsdom 10y ago
The Chromium bug describes the root cause, which is a fixed schedule interval for CSS animations: > The JS implementation uses an interval of 500ms between updates while native animations will be updating at 60Hz. At the moment we're not smart enough to deschedule ourselves during animations with step timing functions. https://bugs.chromium.org/p/chromium/issues/detail?id=500259 https://bugs.chromium.org/p/chromium/issues/detail?id=500259
- petters 10y ago
  The fact that animating a cursor at 60Hz requires non-neglible CPU is still a little sad.
tomc1985 10y ago
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?
- joshuamorton 10y ago
  I think the fact that you call java not-compiled, but python interpreted shows your misunderstanding in this area. Both run exactly the same way, they are compiled into an intermediate bytecode which is run in a "VM". The normal Java VM has a JIT, the normal python VM does not, but pypy does and achieves performance on par with some of your compiled languages, at the cost of reduced c compatibility. I know C, Java, python, and a limited amount of javascript and go. I prefer writing python. And, for plugins, there are enormous downsides to using something that is compiled (C, go).
  - tomc1985 10y ago
    Uh, I lumped in Java with the compiled languages? And yeah, thats right there's like 80 million Python variants, some of which are compiled.
    - joshuamorton 10y ago
      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.
      - tomc1985 10y ago
        cpython? I know the regular python-2.7 installer in debian does binary compilation, producing little *.pyc files for everything
        jodrellblank 10y ago
billconan 10y ago
Yesterday I wrote a webpage with a bootstrap template. The webpage has a progress bar that is updated in realtime by a websocket. The webpage is extremely slow. I guess every bit of progress bar update it rerenders the entire dom tree. I don't think react would do much better, but I will have to try.
- billconan 10y ago
  why did this get down voted? I can't understand.
- Guillaume86 10y ago
  With a decent implementation, a progress bar will run at 60 fps no problem. You don't need react for a simple progress bar either, just check no unnecessary is done (probably just need to update the width on an element) and use requestAnimationFrame if you receive updates at very high rate.
  - billconan 10y ago
    I admit I'm not familiar with frontend development. I used this template https://github.com/secondtruth/startmin https://github.com/secondtruth/startmin I noticed that boostrap progress bar is a div, https://www.w3schools.com/Bootstrap/bootstrap_progressbars.asp https://www.w3schools.com/Bootstrap/bootstrap_progressbars.a... that's why I guess updating it triggers dom update. I'm still looking for a solution.
tomc1985 10y ago
The amount of bad hacking that has to happen for NodeJS to work as a platform has said all I could ever want to possibly know about the quality of NodeJS developers: so pathetically in love with their trainwreck of a language that they would rather pile kludge upon hack upon kludge than to learn the language and environment most appropriate and most computationally efficient for the tasks at hand. Javascript devs would rather just throw JS at it
- oblio 10y ago
  This arrogance is amusing. The only thing the web and Javascript world proved is that we are bad. In the past it was much harder to distribute crap since you needed to, you know, find and install everything. Since websites are so frictionless, now we get to experience everything. And guess what, 90% of everything is shit. The current "JS devs" are the former "PHP/Java devs" and the former "VB/Delphi devs" and the former "C/Cobol devs". They're us.
  - tomc1985 10y ago
    My problem isn't with the bad JS (or, in the past, PHP/JAVA and so on) devs themselves, it's that they insist on building an ecosystem out of a really bad platform. Why? Because JS and this "leverage existing skillsets" bullshit. How about leveraging your brain to learn a more appropriate language?
    - oblio 10y ago
      Do you know of a "more appropriate" language for creating cross platform apps that work on Windows, Linux, MacOS, BSDs, iOS, Android, 4k screens and 480p screens? I don't know any.
      - tomc1985 10y ago
        C? C++? QT? Java? Any language with GTK hooks? Xamarin? Juce framework? Delphi?? You say 4K and 480p screens like that's hard. Design once, scale forever?
vgy7ujm 10y ago
The answer: Vim <-- this
LanceH 10y ago
On one hand, I'm annoyed that javascript and browsers are being used for a text editor. On the other hand, I'm reminded of the arguments against emacs using 8 MEGS of memory and how terrible that is. I've learned to just relax and use what works. People have chosen to concentrate on extensibility at the expense of current day performance. The result has been good enough. There is probably something else to be said about these also making OSX a first class citizen, which hasn't always been true.
- RandomOpinion 10y ago
  > On the other hand, I'm reminded of the arguments against emacs using 8 MEGS of memory and how terrible that is. Yeah, but back then Moore's Law was running full steam and we were getting tremendous advances in processor and memory performance every year. Now that era has ended; what processor performance we have today is likely to remain more or less the same for the foreseeable future, barring a miracle from the chipmakers. It's time to stop pissing away performance by using inefficient software stacks and web technologies are a big, juicy target for cleanup.
makecheck 10y ago
Developers often work on extremely fast machines for their own productivity/sanity but this is a reminder that it can help to test on a slower setup from time to time. Or more generally, test edge cases. For instance, if you have a graphics tool that briefly flashes screen updates, the problems are much easier to see. On a fast system, you might not only miss an unnecessary refresh of “everything”, you may miss a repeated refresh of the same content. Also, on slower systems, the cost to generate a frame may delay an entire sequence. Consider something like “live resizing”: on your spiffy machine it seems fluid, on a lesser machine it might be stuttering like crazy. Sometimes you have to cheapen the computations occurring during rendering to make sure it’s OK.
- JustSomeNobody 10y ago
  This ... isn't an edge case.
Skywing 10y ago
Ah yes. The classic text editor debate thread. In this thread you can expect to find folks claiming that 2 seconds of startup time for editors, like Atom, is so disruptive to their workflow that they'd rather use notepad.
- pfooti 10y ago
  Those kids! On my lawn! When we did it, it was uphill, both ways! I prefer letting butterflies flap their wings to change the atmospheric composition in such a way that the cosmic rays flying through the atmosphere bend to flip bits on this disc.
- braveo 10y ago
  Actually, I use notepad for most things on windows specifically for the startup time... only I replace it with akelpad since it's a little more sensible, but the point remains.
- SippinLean 10y ago
  I've switched to VSCode as my go-to text editor and you understate the real impact the poor performance has on my workflow. It's not just startup, almost everything has a 250ms-2s delay; it's not a lot each time but it adds up and is frustrating.
  - equasar 10y ago
    VSCode best use is not for text-editing, its main target is to work as an small version of a full-blown IDE. Use the right tool for the job.
batmansmk 10y ago
This bug has nothing to do with techonology choices. It is just a bug, in chromium. Team is investigating.
rbanffy 10y ago
We could call it Egacs: "Eight Gigabytes And Constantly Swapping"...
angrygoat 10y ago
From 2009 – Much hot air over blinking cursors https://lwn.net/Articles/317922/ https://lwn.net/Articles/317922/ Quote from the article; > The blinking cursor causes the processor and GPU to be woken up frequently. On one of my test systems, this causes somewhere in the region of 2 Watts of extra power consumption. This isn't about electron vs "native" apps. It's just that a smooth cursor animation rendered at 60Hz costs power; and if you look at the github issue, one config setting and that's gone, and so is the power usage when idle.
k__ 10y ago
I don't understand all the hate. Java developers have intelliJ IDEA, Eclipse and Netbeans, all written in Java. JavaScript developers have Atom and VSCode. Since JS was created for HTML, it seems logical for me to use browser tech to build these editors. It allows JS devs to build extensions without the need to learn a different language. As Java devs can build Eclipse plugins with Java. Also, the Electron based editors aren't the only ones available, so it isn't as if someone would force the poor dumb JS developers to use these clunky slow tools, like when Slack built their client with Electron and you had to run a monster app for a simple chat. If they want something faster, there is Sublime, Vim and Emacs...
DonHopkins 10y ago
Rik Arends, who worked on the Cloud9 IDE, has done some amazing work implementing a blazingly fast WebGL based code editor and text formatting and rendering with JavaScript and GPU shaders. He's actually compiling JavaScript code into WebGL shaders! Implementing a WebGL based code editor for JavaScript - Rik Arends - GrunnJS [1] How do you render text and update a code editor when it only has vertexbuffers? What can you do with it? What does an AST editor do to help? Rik Arends (founder of Ajax.org/Cloud9) will blow your mind with the talk. Note that this editor is work in progress. [1] https://www.youtube.com/watch?v=hM1oLr9G3-Q https://www.youtube.com/watch?v=hM1oLr9G3-Q Here are some other talks about his work: Rik Arends: Multi-threaded JavaScript inside Makepad [2] As a web developer since the early 2000s, Rik has lived through the ups and downs of browsers all the way from IE3 to Chrome 52. From doing interactive web projects for big brands to working on Cloud9 IDE, the limitations of HTML have always been there. After leaving Cloud9 four years ago to explore the new possibilities that WebGL offers for UI, a continuous stream of WebGL-related projects have appeared, including a JavaScript trace debugger, a compile-to-JavaScript language and a live coding prototyping framework. Makepad is the latest from-scratch iteration of this WebGL direction, and it is exciting to share the progress and lessons learned. [2] https://www.youtube.com/watch?v=tVTWdFE6-O0 https://www.youtube.com/watch?v=tVTWdFE6-O0 Rik Arends: Beyond HTML and CSS: Fusing Javascript and shaders | JSConf EU 2014 What would the world look like when you can style UI with actual shader programs? The web could be 60fps on mobile, and we can start to imagine what lies beyond HTML and CSS [3] https://www.youtube.com/watch?v=X8xxz-YeWtk https://www.youtube.com/watch?v=X8xxz-YeWtk Here's a demo! [4] [4] https://makepad.github.io/makepad.html https://makepad.github.io/makepad.html
GoToRO 10y ago
I noticed that somethimes when you press TAB at the beginning of a line, it can take about 1s for the TAB to appear on the screen.
qeternity 10y ago
Just another day in the Electron universe. My personal favorite is resource waste of another variety: Slack and WhatsApp using multiple gigs of RAM for unbelievable basic (which is their selling point) chat apps.
- scott_karana 10y ago
  Admittedly, Slack uses tons of memory because animated GIFs do, plus all the other embeds that is supports. /giphy time to burn up ram from everyone in the channel
kardashev 10y ago
I think the reason using the browser for desktop UI is because graphics and UI programming is terrible. The computer architecture and operating systems we use today are built on tech that was before graphics existed. That's why it's trivial to build a terminal app, but god help you if you want to create a window with a button or draw a line. GLEW, GLUT, Qt, OpenGL, and the rest are just kludges to deal with the fact that we're still working with tech from the 70's. Even those kludges are so terrible that companies like Github and Microsoft have resorted to using the browser to make things like Atom and Visual Studio Code. It can be fixed, but I'm not sure anyone has the fortitude to redesign hardware and operating systems.
- jstarks 10y ago
  What hardware or operating system changes do you think are necessary to improve the GUI development experience?
  - kardashev 10y ago
    Imagine being able to create windows, draw, deal with io devices (keyboard, mouse, controller, etc.) and do OpenGL graphics type work with system calls. That would allow (practically) any language to trivially create native apps with a GUI, at least trivially compared to today. In Linux we could eliminate the multitude of complicated display servers and reduce latency in the system (making VR and AR easier to do). Windows has something similar to what I describe, but it's not very good, and has no builtin OpenGL-like system calls. A standardized set of system calls for graphics, GUI, and IO would allow cross platform native apps to be trivially created. In principle there's no reason why MacOS, Windows, and Linux could not have such system calls added. The biggest problem is those systems have become very bloated from adhering to backwards compatibility.
    - coding123 10y ago
      I have also been waiting for the day... Maybe in a few years this Linux subsystem for Windows will start to mold things in this direction?
deleted 10y ago
[deleted]
SippinLean 10y ago
I wonder if adding will-change: opacity to the CSS would improve performance (by switching CSS animation rendering to the GPU) https://medium.com/outsystems-experts/how-to-achieve-60-fps-animations-with-css3-db7b98610108#.2kb4429b9 https://medium.com/outsystems-experts/how-to-achieve-60-fps-...
omegote 10y ago
> 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 honestly doubt the average javascripter could get his head around something like C++, specially for complex tasks like developing an editor.
- Klathmon 10y ago
  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 implement a fast topological sort of a directed acyclic graph off the top of your head like this Javascript developer does. That doesn't make you worse of a developer, it just means you are currently solving other problems that aren't related to that. This stupid bullshit about how you aren't a "real developer" until you've done something needs to fucking stop. It's toxic.
  - ConceptJunkie 10y ago
    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 10y ago
      [deleted]
  - dang 10y ago
    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.
CodeWriter23 10y ago
Why hasn't someone thought of implementing a blinking cursor in hardware, like we did in the early 80's?
- yeukhon 10y ago
  How would that work in reality?
  - CodeWriter23 10y ago
    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.
logicallee 10y ago
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.
- jodrellblank 10y ago
  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.
  - redial 10y ago
    Or stubborn.
ericfrederich 10y ago
Dude... that cursor has a carbon footprint. I hope when Microsoft fixes this they publish some usage stats and we can see how much energy/money/carbon this will save annually.
jankotek 10y ago
It is easy to do screen redrawing wrong. Intellij Idea had similar problem: https://blog.jetbrains.com/idea/2015/08/experimental-zero-latency-typing-in-intellij-idea-15-eap/ https://blog.jetbrains.com/idea/2015/08/experimental-zero-la...
tete 10y ago
This is when I think that the following two minute video should be mandatory for programmers: (Grace Hopper - Nanoseconds) https://www.youtube.com/watch?v=JEpsKnWZrJ8 https://www.youtube.com/watch?v=JEpsKnWZrJ8
c-smile 10y ago
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 window in GPU is not that bad if the renderer is capable of caching GPU objects while rendering. Here is what happens in Sciter (https://sciter.com https://sciter.com) while rendering blinking caret in screen of similar complexity (editor with syntax hihglighting): https://sciter.com/images/sciter-caret-cpu-consumption.png https://sciter.com/images/sciter-caret-cpu-consumption.png As you see it CPU consumption is near to zero.
- phkahler 10y ago
  >>In GDI era caret bar ( that's not cursor, sic!) was rendered as by simply inverting pixels (InvertRect() call) inplace in video frame buffer. And on an old 8-bit system, blinking a cursor involved toggling one byte (character code) in video RAM. How far we have come...
- jblow 10y ago
  "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.
  - c-smile 10y ago
    > There is nothing preventing you from treating an offscreen buffer just like any other buffer of non-dirty pixels. You need: 1. ability to invert pixels by CSS/JS. No such feature in principle. For many reasons. 2. Even if you will be able to invert those pixels in offscreen bitmap you need to send that window's offscreen bitmap to CPU on each caret blink. You can use tiles - so do partial CPU->GPU data transfer but still. 3. If you use offscreen buffer you are almost always use CPU rasterization. CPU rasterization is O(N) operation, where N is a number of pixels. On high-dpi monitors (200dpi...300dpi) number of pixels is 4...9 larger than on "standard" 96dpi monitors. And CPU stay roughly the same last 4-6 years. So if you want your app to run on modern hardware - GPU is the only viable option for rendering - forget about offscreen bitmaps and the like.
kibwen 10y ago
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).
knodi 10y ago
The power of node.js -_-
deleted 10y ago
[deleted]
Animats 10y ago
I had something like this happen with QNX, back in 2004 when we were using it for the DARPA Grand Challenge. We had an industrial x86 computer system that was running headless, with no display. But the device had a minimal VGA controller on the motherboard. So QNX brought up a screen saver on the slow VGA controller, where reading from display memory was very slow. The screen saver was reading from display memory to move the screen saver box around. This used up about 15% of the CPU. The QNX people were really embarrassed about that and fixed the screen saver. We just reconfigured to turn off the display entirely.
eranation 10y ago
This is where Bert Bos (Created jokingly the notorious, unofficial, abused blink tag https://www.w3.org/Style/HTML40-plus-blink.dtd https://www.w3.org/Style/HTML40-plus-blink.dtd) should have a little "told you someone will need it someday" moment ;)
coding123 10y ago
Thank you to the author of this github issue! I hope it gets sorted soon! I use VSCode a lot when disconnected from my power outlet.
kelvin0 10y ago
Simple fix: ... cursor.blink = False // 13% CPU optimization :-) ...
pointernil 10y ago
Thinking about "the stack", runtimes , development processes and the root-causes involved here i think, the best thing that could happen to "the industry" is some event preventing the silicon production to deliver new cpu-s/ram/gpu-s/harddrives for some 5+ years or so. Constrain the resources to bring brack some sane levels of efficiency regarding ram/cpu-cycles/hd-space. /scnr
caseymarquis 10y ago
Crossing my fingers any related changes don't kill the cursor in the vim extension. Maybe I'll skip the next few updates...
- xconverge 10y ago
  Hey bud, I am here for you as a developer of the vscodevim extension. I will make sure it works just for you.
saghm 10y ago
I always turn off cursor blinking everywhere I can because I find it distracting; I never knew I could use "performance" as an excuse! On another note, why is cursor blinking such a universal thing? I assume that other people must like it, or else it wouldn't be so common. Do people have trouble finding their cursor without it, or do they have trouble distinguishing it from actual text? I've never had either of those problems with blinking turned off, but I can't think of any other plausible reason.
- funkyy 10y ago
  I assume it is useful to determine where the cursor is. It is easier to spot blinking element rather than solid.
bitwize 10y ago
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 GUI implementation, and they can't live without the crutches VSCode provides when shitting out Go microservices. Many of these same people will argue vehemently that X11, the shitty GUI layer for Linux that ran perfectly fine 20 years ago, is "slow" and "bloated" and needs to be replaced with Wayland, a new, completely different, shitty GUI layer.
- kchoudhu 10y ago
  If you could n-gate every article as it's posted, that would be awesome.
  - Eiriksmal 10y ago
    For those who missed it, n-gate satirizes some HN posts, to the delight of all: http://n-gate.com/hackernews/ http://n-gate.com/hackernews/
    - znpy 10y ago
      Oh my god... n-gate is pure gold!
      - bshimmin 10y ago
        They had me at "Hacker" "News". Thank you so much for sharing this! (Hell, I mostly quite like HN and I'm sure I'm often part of the problem, and this is still wonderful.)
  - caoxuwen 10y ago
    bummer n-gate didn't comment on its own hn post
agumonkey 10y ago
I hope y'all never have the chance to boot Turbo Pascal 7.0 (DOS) on a P5 class cpu. It's pretty sad. I mean a 700KB IDE with decent language to native code with some form of live check, instantaneous compilation times, modular programming, online help; multiple windows and a cult classic color scheme. It hurts.
roryisok 10y ago
I just checked on Windows 10, an empty instance of VS Code with a blinking cursor uses 0% most of the time. Is this a MacOS only issue? Does it affect Atom?
- acdha 10y ago
  There has to be some other factor: on a 2013 iMac it uses under half a percent when idle, with the same versions of macOS and VS Code.
corford 10y ago
Hilarious. I can reproduce on my Dell Inspiron 15 5000 (core i7 running Windows 10) but it's not as pronounced as in the bug report. CPU usage bounces between 0.5% and 2.5% (which is obviously still ridiculous). I almost want to swap back to using sublime out of protest but vscode's tighter git integration/workflow is hard to give up :( Edit: I've always wondered why vscode couldn't be written in portable C/C++/Rust/D and then embed a V8 engine to power a javascript plugin API (a bit like sublime does with python)?
am185 10y ago
can you close VS Code when not in use?
Ace17 10y ago
No issue, just need a plugin to disable cursor rendering when you launch the build :-)
scriptproof 10y ago
It is amazing this article got more than 700 points because when I open the task manager and VSC is in IDLE, I see 0% in CPU usage. And the cursor is blinking!!!
dingo_bat 10y ago
Don't see this on my Win 10 ultrabook.
camgunz 10y ago
The answer to all this is: "use Qt". "But camgunz, I only know JavaScript" That's cool! Look into QML. "But camgunz, I only know X" That's cool too! Qt4 has a truly ludicrous number of language bindings: https://en.wikipedia.org/wiki/List_of_language_bindings_for_Qt_4 https://en.wikipedia.org/wiki/List_of_language_bindings_for_.... Qt5 has a fair number too: https://wiki.qt.io/Language_Bindings https://wiki.qt.io/Language_Bindings. "But camgunz, I need an embedded browser" I agree, separate windows are for savages. Qt has you covered with Qt WebBrowser. "I need a native look and feel across all platforms" Well, that's a pipe dream. BUT, you can get closer with Qt than anything else. Google for some screenshots. "I need a bananas style but I don't want to write any code" Qt supports CSS-like stylesheets! --- The web isn't a good application platform. Sure we could (and have been) spend billions of engineering hours and years to get it up to speed with exactly what we have now, but that's obviously a bad idea. We can figure out zero-install and sandboxing, but we just don't need to shoehorn everything into JS, weird APIs like localstorage and webrtc, and the DOM. We just don't need to.
- Kamgunz 10y ago
  In what do you prefer to write cross platform apps? Is there a more productive platform? The thing with the web, is that it's very easy for those familiar with it to try and shove into everywhere, I do it too. The amount of code that does things that are useful that one can just steal for his project is very high, with all the fiddles and bins and even more importantly, very accessible and, sometimes, when the gui code, it looks really good too, so people use Electron. BTW, they use Electron because they run the same editor in their Azure platform, as an online editor for files in servers, so knowing this, I'd say picking Electron is a reasonable choice.
  - camgunz 10y ago
    If I need to throw together a GUI app I usually use Python and PySide. I've had co-workers use Qt Creator and they built way better and better looking apps than I did. There are tons of Qt examples and the docs are pretty good. Electron is almost never a reasonable choice. As a platform it's one of the slowest and most limited. You have a choice of a single, pretty bad language. It only works on a few platforms, and in practice it's limited to even fewer because of its poor efficiency. I'm sympathetic to devs that don't want to venture outside of JavaScript, but in the same way we shouldn't pretend that C is a great language to write web backends in, we shouldn't pretend JavaScript is a good choice for anything but the most basic of web scripting. Writing apps in JS, you're going to experience poor performance, high memory usage, a lack of portability, difficulty scaling to a large codebase, and problems with concurrency. You can usually tell when devs choose the wrong tool. If you write a DB in Java, you'll have problems with the GC impacting your latency (Cassandra). If you build a desktop app in JS you'll have weird problems with resource usage (Atom). If you build a web app in C it'll take 4 times as long, be unstable, and have weird restrictions. We should recognize that every tool has its use, and stop wildly spending resources making one tool passable at everything.
joe563323 10y ago
On a not so different not xfce had a bug when the screen saver got displayed after idle timeout the cpu utiliztation rose over 100%.
yAnonymous 10y ago
Why don't all those who complain about Electron apps get together and make a FOSS, cross-platform editor with all the features and an equal or better interface than VS Code and Atom? If you use the time you now spend complaining to code instead, you should have the basics covered.
- angry-hacker 10y ago
  Because there are good enough tools out there already, foss and commercial. This problem is solved already.
  - yAnonymous 10y ago
    Name them.
z3t4 10y ago
You do not need horses to power your computer.
hesarenu 10y ago
Could not Electron use React Native kind of framework?
jokoon 10y ago
This comment section deserve to be posted in some kind of drama-oriented section, a little like /r/subredditdrama Personally I'm waiting for the second net bubble to burst, so that we can force everyone to use a stricter markup language. Everyone is seeing how android apps are slowly but literally making HTML completely obsolete, and honestly that's an awesome thing, because it's really needed. I hope the tech market realizes that and evolve quickly, instead of waiting for some battery breakthrough. Never forget about the Andy Bernhardt video about the birth and death of javascript. Those issues are why I will always target C++/java jobs and laugh at anything related to the "web". I am never short of the amount of analogies I can invent about HTML/JS. It's like comparing stick and stones to a decent steam engine.
nebabyte 10y ago
> Powerful* text editors built on the web stack I've identified the problem

899 points by Kristine1975 10y ago

okket 10y ago

TL;DR: It seems to be a problem in Chromium, the relevant CSS (one second change) results in a 60hz animation cycle. Workaround: "editor.cursorBlinking": "solid"

johnhattan 10y ago
You think this is gonna be fixed in Chromium, fixed in VSCode, or working-as-designed?
- okket 10y ago
  Issues/bugs are filed, see https://github.com/Microsoft/vscode/issues/22900#issuecomment-288529120 https://github.com/Microsoft/vscode/issues/22900#issuecommen...
revelation 10y ago
Okay, but checking at 60 hz if an animation needs to be updated is not relevant work. In no universe should that cause 13% processor load. Sure maybe you can get smarter and realize that all animations run at 2 hz and then also only check at 2 hz, but it seems the root problem here is an entirely different one.
ygra 10y ago
Interesting, considering that CSS animations were supposed to be much better than JS animations in that regard. I guess a simple setInterval would actually perform better here.
- ralfn 10y ago
  CSS animations and raw JS animations perform equally well. JS had a bad reputation for animation only because the common libraries back then (jquery, mootools) had absolute horrible incompetent implementations. This also has nothing to do with the blinking interval. A setInterval would simply not do the same. The CSS animation is fading its opacity at 60 fps not toggling it. Doing the same with a setInterval(.., 1000/60) will use the same amount of CPU. As any introductory tutorial about css animations explains: They interpolate between the percentages you are not providing! So thats a DOM update every 12ms. The reason its smooth is because opacity (like transform) does not trigger a relayout. Finally, whatever is triggering relayouts is not the opacity change, but some other obviously badly written code that is continously triggered on requestAnimationFrame and is touching the DOM even though, zero dom writes should be taking place on idle. (And zero dom reads always! Since reading from the DOM triggers synchronisation between the rendering thread and the js thread)
  - mastax 10y ago
    > The CSS animation is fading its opacity at 60 fps not toggling it. Most of the cursor styles have some sort of animation, but the "blink" style is just an on-off blink with no fade. Chrome updates every animation at 60hz, even step animations like these. This is an acknowledged issue in the Chrome bug tracker as linked in the issue.
artursapek 10y ago
I recently discovered the same issue in a webapp I develop... a simple CSS animation for a "loading" spinner was pegging the CPU. Using steps(n) with a low number basically resolves the issue. https://css-tricks.com/snippets/css/keyframe-animation-syntax/#article-header-id-6 https://css-tricks.com/snippets/css/keyframe-animation-synta... Kind of ridiculous that it's so easy to make this mistake.
- gigatexal 10y ago
  With great power (flexibility of JavaScript) comes great responsibility.

davidascher 10y ago

Reminds me of this ancient Firefox bug about the performance cost of the throbber: https://bugzilla.mozilla.org/show_bug.cgi?id=437829 https://bugzilla.mozilla.org/show_bug.cgi?id=437829

adamnemecek 10y ago

...21st century desktop application development ladies and gentlemen (not that I'm proposing anything constructive).

analognoise 10y ago
Throw it in the bin and return to the old ways, but with modern testing, source control, and static analysis?

Mahn 10y ago

Sounds like this can be fixed by moving away from animating opacity to something more rudimentary like flipping the display property in JS. CSS3 animations from my experience are a bit taxing in general, and something you want to use only in small bursts, not constantly running in the background.

SippinLean 10y ago
That would, but right now the cursor fades in and out, it doesn't "blink" exactly, so this suggestion is not a 1:1 replacement. Sounds like they need to optimize their CSS animations in general.

abrkn 10y ago

I recently switched from Atom to VS Code and have noticed a considerable reduction in lag, especially when using CMD+D and searching through project files.

lotsoflumens 10y ago
Same here - the lag with just doing simple things in Atom, like moving the cursor, became too much. Since I made the switch I've found VS Code to be quite nice. I miss having Hydrogen available but I can always run jupyter notebook if I need something like that.

thecpphorse 10y ago

Google Docs has the exact same behavior and has for years. I can hear my laptop's CPU whining when the cursor fades in and out.

mschaef 10y ago

This reminds me that as part of the Windows95 development effort, Microsoft disabled per-second updates of the taskbar clock to improve performance. Raymond Chen wrote a bit on it back in 2003: https://blogs.msdn.microsoft.com/oldnewthing/20031010-00/?p=42203 https://blogs.msdn.microsoft.com/oldnewthing/20031010-00/?p=...

nihonium 10y ago
On the other hand, iPhone's "Clock" app has an icon that shows the correct time with a super smooth seconds indicator. Which doesn't drain the battery.
- voxic11 10y ago
  How fast does it run on 1995 hardware though?
  - jbmorgado 10y ago
    Pretty sure any sane software implementation of a simple seconds pointer would easily update faster than 1 Hz while using little to negligible CPU time in a Desktop processor from the 90's and onwards.
    - mschaef 10y ago
      The Windows 1.0 clock (1988) had a 1Hz second sweep hand that ran on a 4.77MHz 8088. It's really just a couple clipped line segments each second. http://variableghz.com/wp-content/uploads/2012/12/windows-1.0-clock-app.jpg http://variableghz.com/wp-content/uploads/2012/12/windows-1....
      - jbmorgado 10y ago
        Yes, that was the point I was making. This is something computationally trivial as long as the code is written appropriately.

plg 10y ago

carbon footprint

betaby 10y ago
Yes. We quickly forget what those CPU cycles and abundant of RAM consumes electricity => heating the planet.
- deleted 10y ago
  [deleted]
- valarauca1 10y ago
  The real issue is cooling the universe and accelerating us to the inevitabile heat death :(
  - rikkus 10y ago
    Quick, produce more heat!
GoToRO 10y ago
Yeah. Somebody is putting coal on a fire so I can have a cursor blink on my screen. Makes you think :)

Philipp__ 10y ago

It just doesn't go in my head that we are building text editors inside a web browser! I get it, there are many good use cases for Electron and it's easy to get started with cross platform support, but why is everybody going crazy about text editors in them? Because you can write plugins in JS? Wouldn't it be better to make native application, especially for code editors, where developers spend most of their time, where every noticeable lag and glitches are not appreciated. Edit: Many people here think that I am attacking this web based kind of technology, which I am not, and sorry for not being clear enough, but why chose something so high up the stack for dev tool? Edit2: For non-believers in nested comments, look -> https://github.com/jhallen/joes-sandbox/tree/master/editor-perf https://github.com/jhallen/joes-sandbox/tree/master/editor-p...

jablan 10y ago
I believe making native application for the three platforms would be considerably more effort.
brilliantcode 10y ago
well if you've ever built a cross platform native desktop application, you will appreciate Electron. Java Swing. Never again. edit: Do people downvoting even know what it's like building cross platform desktop applications using Java Swing? It's fucking awful, and that's a fact. Even the end result UI design look & feel is butt ugly. Sure you can spice things up with JavaFX but why? Do you not realize how masochistic it was back then vs now with thin web browser clients? Can't believe people are still thumping Java Swing in 2017.
- krzyk 10y ago
  Why? With JavaFX where you can customize it using CSS it looks nice, and you don't need to use a scripting language to do it.
  - brilliantcode 10y ago
    Why use JavaFX when you can change the CSS in a web app which is indistinguishable? Here's a easy way to get a job done but people refuse to do it because of philosophical/ideological indoctrination. ex. the world is made of objects therefore our languages and how we build software should now mirror it.

aphextron 10y ago

I simply cannot understand why Atom and VSCode are so popular. I get that they are extensible, but is that really worth the slowdown to you? If I need more features than a text editor, I use an actual IDE. Someone just posted some really embarassing benchmark numbers regarding this issue yesterday: https://github.com/jhallen/joes-sandbox/tree/master/editor-perf https://github.com/jhallen/joes-sandbox/tree/master/editor-p... Note that Atom and VSCode are nearly 10x slower than all the other competition, as well as simply crashing for many of the tests. To be fair, I do think Electron based desktop apps have their niche. Spotify is a perfect example. But they have no place in text editing.

swalsh 10y ago
It's not slow to me, I find my computer uses far less resources than say one of the million JetBrain IDE's. Combined with a bunch of useful plugins, it's pretty wonderful.
- sbarre 10y ago
  You're comparing a text editor to an IDE. If you are able to do your work with a text editor, maybe you didn't need an IDE in the first place. IDEs are definitely slower than text editors, but they have their benefits that comes with their tradeoffs (like most things).
  - swalsh 10y ago
    vscode kind of walks a thin line between IDE and text editor. It has an integrated debugger, intellisense, linting, and plugins to do everything you'd expect from an IDE.
tommoor 10y ago
The benchmarks make it look bad but to be honest aren't that relevant for day-to-day use. I can't remember the last time I saw performance issues in Atom and the plugin infrastructure massively outweighs the occasional possible issue

artursapek 10y ago

I'm reminded of this classic: https://github.com/npm/npm/issues/11283 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 apply to VS Code's cursor.

Touche 10y ago
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.
- nolok 10y ago
  > 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 blink on html. I guess they're not using a deprecated <blink> tag is because it's not customizable in any way.
  - kibwen 10y ago
    I don't believe that any modern browser still supports the blink tag; IIRC Firefox was the last to get rid of it, a year or two ago. You can hack it up in CSS, though.
    - ethbro 10y ago
      Truly, the web has come full circle.

drzaiusapelord 10y ago

>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? Microsoft needs to stop it with these terrible levels of QC. Its inexcusable.

StyloBill 10y ago
It's a Chromium problem, maybe you should read the Github issue before commenting.
- big_paps 10y ago
  Still its one of the most interesting posts. x Joules per blink
  - StyloBill 10y ago
    The maths may be interesting, the rant is definitively not.
fao_ 10y ago
> Power savings shouldn't be seen as irrelevant geekery. It seems that these days anything that a developer doesn't care about is seen as "irrelevant geekery".
jodrellblank 10y ago
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?

mmarks 10y ago

13% cpu usage at the lowest c-state is a also very different than 13% at an elevated c-states. I've recently spent a lot of time analyzing c-states/p-states and the power mgmt modes of the GPU. After learning more about the complexity behind the clocks, bus speeds, etc. underlying each state, whenever I hear someone quote a utilization number of a minor workload, I want to know at what power state. Not to take away but the author's point, just an aside that utilization numbers can be a lot more complicated when there are dozens of energy states and the utilization might be utilization at a particular state rather than utilization at maximum power

aarongolliver 10y ago
You mean p-states in your first sentence, right? Anything but c0 represents different levels of 'retiring no instructions' (totally idle). The rest of your comment seems accurate though.
- mmarks 10y ago
  You're correct that I just meant a lower power state. The author mentioned blinking cursor, so it reminded me of graphics issues. A more efficient CPU state has the possibility of slowing an app due to CPU-GPU sync points. A blocking CPU in an energy efficient state can reawaken slower from GPU done notifications, so FPS is lower. So both c-state and p-states can affect performance. General point was just utilization may not be utilization at max power. I've worked on problems where utilization was 15% at lower power and it was a problem. But to compare different workloads, it'd be < 1% at max power.
rasz 10y ago
even the best case scenario is 13% of ~900MHz, 100MHz to blink 20 pixels.
gpderetta 10y ago
That's actually even worse: it will prevent the cpu to enter deep sleep states and save more power. A while ago I was trying to minimize the power usage of my laptop (yeah, slow day) to maximize my battery time. Armed with powertop, I removed any undesired process until I was left with an otherwise idle emacs (less than 1<% cpu) as the last major source of wakeups. Sure enough, disabling the blinking cursor brought that down to nothing, allowing the cpu to stay into deep sleep state much longer.

onli 10y ago

Because it hasn't been mentioned yet, as far as I could see: Blinking cursors are horrible and should never exist, it resembles torture. http://www.jurta.org/en/prog/noblink http://www.jurta.org/en/prog/noblink is an extensive list with ways to deactivate it in various programs. Try it out, you will feel the difference.

juandazapata 10y ago
I don't like XXX, so it shouldn't exist it's a great argument.
- onli 10y ago
  No, of course not. It wasn't supposed to be the argument. Are you really interested in the background? I will just assume so, this is HN after all. Our brain has some special recognition for specific things. A collection of those things are bundled under Gestalt psychology. There are also a number of things that make something pop out. Now, movement triggers the pop out effect, it is one of those things that we notice immediately. What that means in practice is that a blinking cursor in an otherwise plain image will be noticed immediately, and it takes conscious effort to ignore it. That is a strain on your mental capacities, and highly unnerving, even if you are not completely aware of what it is that annoys you. Parts of this is what motivates those specialized writer editors, that remove everything apart from pure trext to make it as easy as possible to focus on the task at hand. Blinking cursors, and this is what the jurta page mentions, also resemble the chinese waterdrop torture. I think that was meant a bit tongue in cheek, but is actually not wrong. It comes again and again and again and again ..., and it not immediately controllable. Add to that the useless resource usage like in this bug and yes, I stand to that and am serious about it: Blinking cursors are a very bad habit that should just die out. And developers that actively implement it without making it deactivable should ask themselves what they are doing - I had that with Sharelatex, a platform which I otherwise like a lot.
rastapasta42 10y ago
Personally I like the blinking cursor in vim and I don't think dripping water is a good comparison. Without the blinking I lose the file location and have to move it around with "hjkl" so I can find it again.

ChuckMcM 10y ago

I love the irony of simulating an XOR gate from a piece of hardware (a serial terminal) with a billion gates in a processor which renders a square with an alpha blend function. Sort of like using a 787 to sit on the runway, and run its engines to blow a windmill to crank a butter churn :-).

dahart 10y ago
That's a fun analogy, made me laugh. :) I see this literally everywhere though, the article at hand is only a slightly better example than almost everything we do. Browsers consume gigabytes of memory to render a few basic web pages. We use high level scripting languages with tons of dynamic memory inside containers that are running on VMs to run all our cloud infrastructure. If we had the time, these things could be multiple orders of magnitude faster and smaller. It just isn't worth our time... :P Another fun example of this I ran into recently is the controllers for brushless drone propellers. The hobby motors you buy for $20 usually have a 1Mhz 8-bit CPU running Electronic speed control, literally shrink-wrapped inside the wires. Every single prop. Think about that, a million instructions per second running, only to make something spin. (To be fair, the CPUs are under-utilized, but still, it reminds me of churning butter with a jetplane.) The main difference, of course, is that cpu time & memory are close to free, and 787's are super expensive. Maybe if 787's were free, we'd use 'em often to churn butter... ;)
- eeZah7Ux 10y ago
  > cpu time & memory are close to free Not for 3 billion people. Also energy is not free at all.
  - dahart 10y ago
    Right yes, I know, and it's a great point. Global economics and third world access to computing & the internet are in a completely different time zone from I was talking about. But you're right, and on the global scale, we may actually be doing the equivalent of churning butter with jets. I totally wouldn't be surprised if the sum total energy expenditure on all computers in the world was greater than on all the aircraft in the world... and we are most definitely wasting the vast majority of the energy we use on computation. Still, in my defense, I said close to free, and compared to the cost of a 787, cpu time & memory are closer to free than jets, no matter who we're talking about, right?

excalibur 10y ago

Lotus Notes FTW

ohitsdom 10y ago

The Chromium bug describes the root cause, which is a fixed schedule interval for CSS animations: > The JS implementation uses an interval of 500ms between updates while native animations will be updating at 60Hz. At the moment we're not smart enough to deschedule ourselves during animations with step timing functions. https://bugs.chromium.org/p/chromium/issues/detail?id=500259 https://bugs.chromium.org/p/chromium/issues/detail?id=500259

petters 10y ago
The fact that animating a cursor at 60Hz requires non-neglible CPU is still a little sad.

tomc1985 10y ago

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?

joshuamorton 10y ago
I think the fact that you call java not-compiled, but python interpreted shows your misunderstanding in this area. Both run exactly the same way, they are compiled into an intermediate bytecode which is run in a "VM". The normal Java VM has a JIT, the normal python VM does not, but pypy does and achieves performance on par with some of your compiled languages, at the cost of reduced c compatibility. I know C, Java, python, and a limited amount of javascript and go. I prefer writing python. And, for plugins, there are enormous downsides to using something that is compiled (C, go).
- tomc1985 10y ago
  Uh, I lumped in Java with the compiled languages? And yeah, thats right there's like 80 million Python variants, some of which are compiled.
  - joshuamorton 10y ago
    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.
    - tomc1985 10y ago
      cpython? I know the regular python-2.7 installer in debian does binary compilation, producing little *.pyc files for everything
      - jodrellblank 10y ago

billconan 10y ago

Yesterday I wrote a webpage with a bootstrap template. The webpage has a progress bar that is updated in realtime by a websocket. The webpage is extremely slow. I guess every bit of progress bar update it rerenders the entire dom tree. I don't think react would do much better, but I will have to try.

billconan 10y ago
why did this get down voted? I can't understand.
Guillaume86 10y ago
With a decent implementation, a progress bar will run at 60 fps no problem. You don't need react for a simple progress bar either, just check no unnecessary is done (probably just need to update the width on an element) and use requestAnimationFrame if you receive updates at very high rate.
- billconan 10y ago
  I admit I'm not familiar with frontend development. I used this template https://github.com/secondtruth/startmin https://github.com/secondtruth/startmin I noticed that boostrap progress bar is a div, https://www.w3schools.com/Bootstrap/bootstrap_progressbars.asp https://www.w3schools.com/Bootstrap/bootstrap_progressbars.a... that's why I guess updating it triggers dom update. I'm still looking for a solution.

tomc1985 10y ago

The amount of bad hacking that has to happen for NodeJS to work as a platform has said all I could ever want to possibly know about the quality of NodeJS developers: so pathetically in love with their trainwreck of a language that they would rather pile kludge upon hack upon kludge than to learn the language and environment most appropriate and most computationally efficient for the tasks at hand. Javascript devs would rather just throw JS at it

oblio 10y ago
This arrogance is amusing. The only thing the web and Javascript world proved is that we are bad. In the past it was much harder to distribute crap since you needed to, you know, find and install everything. Since websites are so frictionless, now we get to experience everything. And guess what, 90% of everything is shit. The current "JS devs" are the former "PHP/Java devs" and the former "VB/Delphi devs" and the former "C/Cobol devs". They're us.
- tomc1985 10y ago
  My problem isn't with the bad JS (or, in the past, PHP/JAVA and so on) devs themselves, it's that they insist on building an ecosystem out of a really bad platform. Why? Because JS and this "leverage existing skillsets" bullshit. How about leveraging your brain to learn a more appropriate language?
  - oblio 10y ago
    Do you know of a "more appropriate" language for creating cross platform apps that work on Windows, Linux, MacOS, BSDs, iOS, Android, 4k screens and 480p screens? I don't know any.
    - tomc1985 10y ago
      C? C++? QT? Java? Any language with GTK hooks? Xamarin? Juce framework? Delphi?? You say 4K and 480p screens like that's hard. Design once, scale forever?

vgy7ujm 10y ago

The answer: Vim <-- this

LanceH 10y ago

On one hand, I'm annoyed that javascript and browsers are being used for a text editor. On the other hand, I'm reminded of the arguments against emacs using 8 MEGS of memory and how terrible that is. I've learned to just relax and use what works. People have chosen to concentrate on extensibility at the expense of current day performance. The result has been good enough. There is probably something else to be said about these also making OSX a first class citizen, which hasn't always been true.

RandomOpinion 10y ago
> On the other hand, I'm reminded of the arguments against emacs using 8 MEGS of memory and how terrible that is. Yeah, but back then Moore's Law was running full steam and we were getting tremendous advances in processor and memory performance every year. Now that era has ended; what processor performance we have today is likely to remain more or less the same for the foreseeable future, barring a miracle from the chipmakers. It's time to stop pissing away performance by using inefficient software stacks and web technologies are a big, juicy target for cleanup.

makecheck 10y ago

Developers often work on extremely fast machines for their own productivity/sanity but this is a reminder that it can help to test on a slower setup from time to time. Or more generally, test edge cases. For instance, if you have a graphics tool that briefly flashes screen updates, the problems are much easier to see. On a fast system, you might not only miss an unnecessary refresh of “everything”, you may miss a repeated refresh of the same content. Also, on slower systems, the cost to generate a frame may delay an entire sequence. Consider something like “live resizing”: on your spiffy machine it seems fluid, on a lesser machine it might be stuttering like crazy. Sometimes you have to cheapen the computations occurring during rendering to make sure it’s OK.

JustSomeNobody 10y ago
This ... isn't an edge case.

Skywing 10y ago

Ah yes. The classic text editor debate thread. In this thread you can expect to find folks claiming that 2 seconds of startup time for editors, like Atom, is so disruptive to their workflow that they'd rather use notepad.

pfooti 10y ago
Those kids! On my lawn! When we did it, it was uphill, both ways! I prefer letting butterflies flap their wings to change the atmospheric composition in such a way that the cosmic rays flying through the atmosphere bend to flip bits on this disc.
braveo 10y ago
Actually, I use notepad for most things on windows specifically for the startup time... only I replace it with akelpad since it's a little more sensible, but the point remains.
SippinLean 10y ago
I've switched to VSCode as my go-to text editor and you understate the real impact the poor performance has on my workflow. It's not just startup, almost everything has a 250ms-2s delay; it's not a lot each time but it adds up and is frustrating.
- equasar 10y ago
  VSCode best use is not for text-editing, its main target is to work as an small version of a full-blown IDE. Use the right tool for the job.

batmansmk 10y ago

This bug has nothing to do with techonology choices. It is just a bug, in chromium. Team is investigating.

rbanffy 10y ago

We could call it Egacs: "Eight Gigabytes And Constantly Swapping"...

angrygoat 10y ago

From 2009 – Much hot air over blinking cursors https://lwn.net/Articles/317922/ https://lwn.net/Articles/317922/ Quote from the article; > The blinking cursor causes the processor and GPU to be woken up frequently. On one of my test systems, this causes somewhere in the region of 2 Watts of extra power consumption. This isn't about electron vs "native" apps. It's just that a smooth cursor animation rendered at 60Hz costs power; and if you look at the github issue, one config setting and that's gone, and so is the power usage when idle.

k__ 10y ago

I don't understand all the hate. Java developers have intelliJ IDEA, Eclipse and Netbeans, all written in Java. JavaScript developers have Atom and VSCode. Since JS was created for HTML, it seems logical for me to use browser tech to build these editors. It allows JS devs to build extensions without the need to learn a different language. As Java devs can build Eclipse plugins with Java. Also, the Electron based editors aren't the only ones available, so it isn't as if someone would force the poor dumb JS developers to use these clunky slow tools, like when Slack built their client with Electron and you had to run a monster app for a simple chat. If they want something faster, there is Sublime, Vim and Emacs...

DonHopkins 10y ago

Rik Arends, who worked on the Cloud9 IDE, has done some amazing work implementing a blazingly fast WebGL based code editor and text formatting and rendering with JavaScript and GPU shaders. He's actually compiling JavaScript code into WebGL shaders! Implementing a WebGL based code editor for JavaScript - Rik Arends - GrunnJS [1] How do you render text and update a code editor when it only has vertexbuffers? What can you do with it? What does an AST editor do to help? Rik Arends (founder of Ajax.org/Cloud9) will blow your mind with the talk. Note that this editor is work in progress. [1] https://www.youtube.com/watch?v=hM1oLr9G3-Q https://www.youtube.com/watch?v=hM1oLr9G3-Q Here are some other talks about his work: Rik Arends: Multi-threaded JavaScript inside Makepad [2] As a web developer since the early 2000s, Rik has lived through the ups and downs of browsers all the way from IE3 to Chrome 52. From doing interactive web projects for big brands to working on Cloud9 IDE, the limitations of HTML have always been there. After leaving Cloud9 four years ago to explore the new possibilities that WebGL offers for UI, a continuous stream of WebGL-related projects have appeared, including a JavaScript trace debugger, a compile-to-JavaScript language and a live coding prototyping framework. Makepad is the latest from-scratch iteration of this WebGL direction, and it is exciting to share the progress and lessons learned. [2] https://www.youtube.com/watch?v=tVTWdFE6-O0 https://www.youtube.com/watch?v=tVTWdFE6-O0 Rik Arends: Beyond HTML and CSS: Fusing Javascript and shaders | JSConf EU 2014 What would the world look like when you can style UI with actual shader programs? The web could be 60fps on mobile, and we can start to imagine what lies beyond HTML and CSS [3] https://www.youtube.com/watch?v=X8xxz-YeWtk https://www.youtube.com/watch?v=X8xxz-YeWtk Here's a demo! [4] [4] https://makepad.github.io/makepad.html https://makepad.github.io/makepad.html

GoToRO 10y ago

I noticed that somethimes when you press TAB at the beginning of a line, it can take about 1s for the TAB to appear on the screen.

qeternity 10y ago

Just another day in the Electron universe. My personal favorite is resource waste of another variety: Slack and WhatsApp using multiple gigs of RAM for unbelievable basic (which is their selling point) chat apps.

scott_karana 10y ago
Admittedly, Slack uses tons of memory because animated GIFs do, plus all the other embeds that is supports. /giphy time to burn up ram from everyone in the channel

kardashev 10y ago

I think the reason using the browser for desktop UI is because graphics and UI programming is terrible. The computer architecture and operating systems we use today are built on tech that was before graphics existed. That's why it's trivial to build a terminal app, but god help you if you want to create a window with a button or draw a line. GLEW, GLUT, Qt, OpenGL, and the rest are just kludges to deal with the fact that we're still working with tech from the 70's. Even those kludges are so terrible that companies like Github and Microsoft have resorted to using the browser to make things like Atom and Visual Studio Code. It can be fixed, but I'm not sure anyone has the fortitude to redesign hardware and operating systems.

jstarks 10y ago
What hardware or operating system changes do you think are necessary to improve the GUI development experience?
- kardashev 10y ago
  Imagine being able to create windows, draw, deal with io devices (keyboard, mouse, controller, etc.) and do OpenGL graphics type work with system calls. That would allow (practically) any language to trivially create native apps with a GUI, at least trivially compared to today. In Linux we could eliminate the multitude of complicated display servers and reduce latency in the system (making VR and AR easier to do). Windows has something similar to what I describe, but it's not very good, and has no builtin OpenGL-like system calls. A standardized set of system calls for graphics, GUI, and IO would allow cross platform native apps to be trivially created. In principle there's no reason why MacOS, Windows, and Linux could not have such system calls added. The biggest problem is those systems have become very bloated from adhering to backwards compatibility.
  - coding123 10y ago
    I have also been waiting for the day... Maybe in a few years this Linux subsystem for Windows will start to mold things in this direction?

deleted 10y ago

[deleted]

SippinLean 10y ago

I wonder if adding will-change: opacity to the CSS would improve performance (by switching CSS animation rendering to the GPU) https://medium.com/outsystems-experts/how-to-achieve-60-fps-animations-with-css3-db7b98610108#.2kb4429b9 https://medium.com/outsystems-experts/how-to-achieve-60-fps-...

omegote 10y ago

> 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 honestly doubt the average javascripter could get his head around something like C++, specially for complex tasks like developing an editor.

Klathmon 10y ago
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 implement a fast topological sort of a directed acyclic graph off the top of your head like this Javascript developer does. That doesn't make you worse of a developer, it just means you are currently solving other problems that aren't related to that. This stupid bullshit about how you aren't a "real developer" until you've done something needs to fucking stop. It's toxic.
- ConceptJunkie 10y ago
  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 10y ago
    [deleted]
- dang 10y ago
  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.

CodeWriter23 10y ago

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

yeukhon 10y ago
How would that work in reality?
- CodeWriter23 10y ago
  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.

logicallee 10y ago

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.

jodrellblank 10y ago
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.
- redial 10y ago
  Or stubborn.

ericfrederich 10y ago

Dude... that cursor has a carbon footprint. I hope when Microsoft fixes this they publish some usage stats and we can see how much energy/money/carbon this will save annually.

jankotek 10y ago

It is easy to do screen redrawing wrong. Intellij Idea had similar problem: https://blog.jetbrains.com/idea/2015/08/experimental-zero-latency-typing-in-intellij-idea-15-eap/ https://blog.jetbrains.com/idea/2015/08/experimental-zero-la...

tete 10y ago

This is when I think that the following two minute video should be mandatory for programmers: (Grace Hopper - Nanoseconds) https://www.youtube.com/watch?v=JEpsKnWZrJ8 https://www.youtube.com/watch?v=JEpsKnWZrJ8

c-smile 10y ago

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 window in GPU is not that bad if the renderer is capable of caching GPU objects while rendering. Here is what happens in Sciter (https://sciter.com https://sciter.com) while rendering blinking caret in screen of similar complexity (editor with syntax hihglighting): https://sciter.com/images/sciter-caret-cpu-consumption.png https://sciter.com/images/sciter-caret-cpu-consumption.png As you see it CPU consumption is near to zero.

phkahler 10y ago
>>In GDI era caret bar ( that's not cursor, sic!) was rendered as by simply inverting pixels (InvertRect() call) inplace in video frame buffer. And on an old 8-bit system, blinking a cursor involved toggling one byte (character code) in video RAM. How far we have come...
jblow 10y ago
"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.
- c-smile 10y ago
  > There is nothing preventing you from treating an offscreen buffer just like any other buffer of non-dirty pixels. You need: 1. ability to invert pixels by CSS/JS. No such feature in principle. For many reasons. 2. Even if you will be able to invert those pixels in offscreen bitmap you need to send that window's offscreen bitmap to CPU on each caret blink. You can use tiles - so do partial CPU->GPU data transfer but still. 3. If you use offscreen buffer you are almost always use CPU rasterization. CPU rasterization is O(N) operation, where N is a number of pixels. On high-dpi monitors (200dpi...300dpi) number of pixels is 4...9 larger than on "standard" 96dpi monitors. And CPU stay roughly the same last 4-6 years. So if you want your app to run on modern hardware - GPU is the only viable option for rendering - forget about offscreen bitmaps and the like.

kibwen 10y ago

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

knodi 10y ago

The power of node.js -_-

deleted 10y ago

[deleted]

Animats 10y ago

I had something like this happen with QNX, back in 2004 when we were using it for the DARPA Grand Challenge. We had an industrial x86 computer system that was running headless, with no display. But the device had a minimal VGA controller on the motherboard. So QNX brought up a screen saver on the slow VGA controller, where reading from display memory was very slow. The screen saver was reading from display memory to move the screen saver box around. This used up about 15% of the CPU. The QNX people were really embarrassed about that and fixed the screen saver. We just reconfigured to turn off the display entirely.

eranation 10y ago

This is where Bert Bos (Created jokingly the notorious, unofficial, abused blink tag https://www.w3.org/Style/HTML40-plus-blink.dtd https://www.w3.org/Style/HTML40-plus-blink.dtd) should have a little "told you someone will need it someday" moment ;)

coding123 10y ago

Thank you to the author of this github issue! I hope it gets sorted soon! I use VSCode a lot when disconnected from my power outlet.

kelvin0 10y ago

Simple fix: ... cursor.blink = False // 13% CPU optimization :-) ...

pointernil 10y ago

Thinking about "the stack", runtimes , development processes and the root-causes involved here i think, the best thing that could happen to "the industry" is some event preventing the silicon production to deliver new cpu-s/ram/gpu-s/harddrives for some 5+ years or so. Constrain the resources to bring brack some sane levels of efficiency regarding ram/cpu-cycles/hd-space. /scnr

caseymarquis 10y ago

Crossing my fingers any related changes don't kill the cursor in the vim extension. Maybe I'll skip the next few updates...

xconverge 10y ago
Hey bud, I am here for you as a developer of the vscodevim extension. I will make sure it works just for you.

saghm 10y ago

I always turn off cursor blinking everywhere I can because I find it distracting; I never knew I could use "performance" as an excuse! On another note, why is cursor blinking such a universal thing? I assume that other people must like it, or else it wouldn't be so common. Do people have trouble finding their cursor without it, or do they have trouble distinguishing it from actual text? I've never had either of those problems with blinking turned off, but I can't think of any other plausible reason.

funkyy 10y ago
I assume it is useful to determine where the cursor is. It is easier to spot blinking element rather than solid.

bitwize 10y ago

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 GUI implementation, and they can't live without the crutches VSCode provides when shitting out Go microservices. Many of these same people will argue vehemently that X11, the shitty GUI layer for Linux that ran perfectly fine 20 years ago, is "slow" and "bloated" and needs to be replaced with Wayland, a new, completely different, shitty GUI layer.

kchoudhu 10y ago
If you could n-gate every article as it's posted, that would be awesome.
- Eiriksmal 10y ago
  For those who missed it, n-gate satirizes some HN posts, to the delight of all: http://n-gate.com/hackernews/ http://n-gate.com/hackernews/
  - znpy 10y ago
    Oh my god... n-gate is pure gold!
    - bshimmin 10y ago
      They had me at "Hacker" "News". Thank you so much for sharing this! (Hell, I mostly quite like HN and I'm sure I'm often part of the problem, and this is still wonderful.)
- caoxuwen 10y ago
  bummer n-gate didn't comment on its own hn post

agumonkey 10y ago

I hope y'all never have the chance to boot Turbo Pascal 7.0 (DOS) on a P5 class cpu. It's pretty sad. I mean a 700KB IDE with decent language to native code with some form of live check, instantaneous compilation times, modular programming, online help; multiple windows and a cult classic color scheme. It hurts.

roryisok 10y ago

I just checked on Windows 10, an empty instance of VS Code with a blinking cursor uses 0% most of the time. Is this a MacOS only issue? Does it affect Atom?

acdha 10y ago
There has to be some other factor: on a 2013 iMac it uses under half a percent when idle, with the same versions of macOS and VS Code.

corford 10y ago

Hilarious. I can reproduce on my Dell Inspiron 15 5000 (core i7 running Windows 10) but it's not as pronounced as in the bug report. CPU usage bounces between 0.5% and 2.5% (which is obviously still ridiculous). I almost want to swap back to using sublime out of protest but vscode's tighter git integration/workflow is hard to give up :( Edit: I've always wondered why vscode couldn't be written in portable C/C++/Rust/D and then embed a V8 engine to power a javascript plugin API (a bit like sublime does with python)?

am185 10y ago

can you close VS Code when not in use?

Ace17 10y ago

No issue, just need a plugin to disable cursor rendering when you launch the build :-)

scriptproof 10y ago

It is amazing this article got more than 700 points because when I open the task manager and VSC is in IDLE, I see 0% in CPU usage. And the cursor is blinking!!!

dingo_bat 10y ago

Don't see this on my Win 10 ultrabook.

camgunz 10y ago

The answer to all this is: "use Qt". "But camgunz, I only know JavaScript" That's cool! Look into QML. "But camgunz, I only know X" That's cool too! Qt4 has a truly ludicrous number of language bindings: https://en.wikipedia.org/wiki/List_of_language_bindings_for_Qt_4 https://en.wikipedia.org/wiki/List_of_language_bindings_for_.... Qt5 has a fair number too: https://wiki.qt.io/Language_Bindings https://wiki.qt.io/Language_Bindings. "But camgunz, I need an embedded browser" I agree, separate windows are for savages. Qt has you covered with Qt WebBrowser. "I need a native look and feel across all platforms" Well, that's a pipe dream. BUT, you can get closer with Qt than anything else. Google for some screenshots. "I need a bananas style but I don't want to write any code" Qt supports CSS-like stylesheets! --- The web isn't a good application platform. Sure we could (and have been) spend billions of engineering hours and years to get it up to speed with exactly what we have now, but that's obviously a bad idea. We can figure out zero-install and sandboxing, but we just don't need to shoehorn everything into JS, weird APIs like localstorage and webrtc, and the DOM. We just don't need to.

Kamgunz 10y ago
In what do you prefer to write cross platform apps? Is there a more productive platform? The thing with the web, is that it's very easy for those familiar with it to try and shove into everywhere, I do it too. The amount of code that does things that are useful that one can just steal for his project is very high, with all the fiddles and bins and even more importantly, very accessible and, sometimes, when the gui code, it looks really good too, so people use Electron. BTW, they use Electron because they run the same editor in their Azure platform, as an online editor for files in servers, so knowing this, I'd say picking Electron is a reasonable choice.
- camgunz 10y ago
  If I need to throw together a GUI app I usually use Python and PySide. I've had co-workers use Qt Creator and they built way better and better looking apps than I did. There are tons of Qt examples and the docs are pretty good. Electron is almost never a reasonable choice. As a platform it's one of the slowest and most limited. You have a choice of a single, pretty bad language. It only works on a few platforms, and in practice it's limited to even fewer because of its poor efficiency. I'm sympathetic to devs that don't want to venture outside of JavaScript, but in the same way we shouldn't pretend that C is a great language to write web backends in, we shouldn't pretend JavaScript is a good choice for anything but the most basic of web scripting. Writing apps in JS, you're going to experience poor performance, high memory usage, a lack of portability, difficulty scaling to a large codebase, and problems with concurrency. You can usually tell when devs choose the wrong tool. If you write a DB in Java, you'll have problems with the GC impacting your latency (Cassandra). If you build a desktop app in JS you'll have weird problems with resource usage (Atom). If you build a web app in C it'll take 4 times as long, be unstable, and have weird restrictions. We should recognize that every tool has its use, and stop wildly spending resources making one tool passable at everything.

joe563323 10y ago

On a not so different not xfce had a bug when the screen saver got displayed after idle timeout the cpu utiliztation rose over 100%.

yAnonymous 10y ago

Why don't all those who complain about Electron apps get together and make a FOSS, cross-platform editor with all the features and an equal or better interface than VS Code and Atom? If you use the time you now spend complaining to code instead, you should have the basics covered.

angry-hacker 10y ago
Because there are good enough tools out there already, foss and commercial. This problem is solved already.
- yAnonymous 10y ago
  Name them.

z3t4 10y ago

You do not need horses to power your computer.

hesarenu 10y ago

Could not Electron use React Native kind of framework?

jokoon 10y ago

This comment section deserve to be posted in some kind of drama-oriented section, a little like /r/subredditdrama Personally I'm waiting for the second net bubble to burst, so that we can force everyone to use a stricter markup language. Everyone is seeing how android apps are slowly but literally making HTML completely obsolete, and honestly that's an awesome thing, because it's really needed. I hope the tech market realizes that and evolve quickly, instead of waiting for some battery breakthrough. Never forget about the Andy Bernhardt video about the birth and death of javascript. Those issues are why I will always target C++/java jobs and laugh at anything related to the "web". I am never short of the amount of analogies I can invent about HTML/JS. It's like comparing stick and stones to a decent steam engine.

nebabyte 10y ago

> Powerful* text editors built on the web stack I've identified the problem