VS Code uses 13% CPU when idle due to blinking cursor rendering
github.com
github.com
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.
A long while back (seems like this was the late 90s or early 2000s) I was working on a script that did some data processing on a remote machine. It had to loop through a bunch of text log data and generate some reports. Being as that I had no idea if the script was actually working until it completed awhile later, I decided to put in a neat little ASCII spinner in it when you ran it with verbose options.
At the time I was on a slow dialup connection as I was on break from school, and something weird would happen. Every time I ran the script to test it, my Internet connection would become nearly unusable. But as soon as the script finished, it would suddenly start working again.
As you can imagine, this was very confusing since the script was running entirely on a remote system. What the hell is going on?
This stumped me for an hour or so until I ran it without the verbose option ... and it didn't happen. Then I finally realized what was happening: I was refreshing the spinner on EACH ROW and remote machine was going through the rows so quickly that sending refreshes for the spinner saturated my tiny dial-up connection. Changing this to only update once a second fixed it entirely.
And that's how I DoS'd myself with a spinner.
P.S. I have sped up my shit. That process originally took days, now it takes an hour.
I still hark back to the days of the C64 and the likes in which had tape storage and was common to have a game as a loading screen to play. Was a small program and used to give the user something to do whilst they waited 20 minutes for the program to load. Many also rewrote the cassette storage code for faster storage/loading and would often be a case of loading that program with the small game like space invaders that you could play whilst the main game loaded utilising the quicker tape handling code.
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.
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-p...
Ultimately, computing has always been one of abstraction from the lower "layers". Taken far enough, one could spuriously argue that if you aren't soldering together the flip-flops that make up your logic and memory, you just aren't being efficient...
I doubt much of that time is spent building the DOM tree for the UI. Google Docs does a lot more than a simple text editing widget - there's a networked file system, a multi-user collaboration engine, a realtime notification system, etc that all get initialised. Instantiating all that over a network in 2-3 seconds is really fast.
"Writing directly to the screen" (by which I assume you mean writing pixels one by one to the framebuffer) is a bad idea for modern graphics hardware. It was fine on the 486, but nowadays you need the ability to do global optimizations for good 2D (or 3D) graphics performance. Ironically, the Web stack is much better positioned to do this than, say, Win32, because of the declarative nature of CSS.
Besides, as some downthread have pointed out, you didn't "write directly to the screen" in Win32. You went through GDI.
Most "modern" mainstream native toolkits - e.g. GTK+ 3, Qt 5, WPF - encourage this separation into layout - GtkBuilder, QML, XAML - and style - CSS, Qt Style Sheets, XAML Styles.
So, this isn't a "web browser" problem. Or, this style of GUI isn't the problem with Electron. I find GTK and Qt apps to be plenty responsive enough, even when their GUIs are loaded from XML files.
Given all these factors, any product using web technologies for UI can move much faster than products which don't. Like how Sublime and every other programming text editor basically got eaten up by VSCode and Atom in about a year and half.
Why invent a new standard? HTML is fine, CSS is fine. Most importantly, everyone understands it and can work immediately with it.
Any issues with performance is due to the implementation of the platform that renders this HTML/CSS interface. It's much more likely Google Docs feels sluggish due to the javascript it executes in order to control the rendering of its html/css, rather than the rendering itself.
I know which I'd rather offer as my toolkit of choice for a project on which I wanted lots of people to contribute code to!
Something will come in and replace HTML, it's just a matter of time. The main driver is mobile. The many layers of abstraction burn battery, one day phone manufacturers will get tired of it and do something.
For instance I wanted to be able to display PDFs directly in VSCode. I went to look for a plugin, and there was one. People simply used "pdf.js" to integrate PDF support in VSCode. Because it is web based it should have been straightforward to do. Doing the same with native technology would have took several weeks of coding, and it wouldn't have been cross-platform.
Imagine all the web-based open-source tools that could potentially be integrated in these editors. Integrating a SVG editor in native text editors would be a nightmare. With web-based text editor you can potentially just incorporate an existing tool like [1].
There are lot of other examples like this: Live markdown preview, mini-map, color-picker, integrated VSCode debug panel, …
It is also quite easy to add visual stuff. For instance adding a vertical bar at 80 characters in the background is quite easy to do with web technologies. On the other side emacs has still not managed yet to make the html-mode work nicely with this "fill-column-indicator". It is also probable that it would be much more easy to integrate web services (trello, github, …) directly within VSCode.
At the end people wanting performances have already quite a lot of choice in native text editors (vim, emacs, sublime…), and people who prefer functionalities can go with web-based text editors (atom, vscode, …)
[1] https://svg-edit.github.io/svgedit/releases/svg-edit-2.8.1/s...
Actually, it would take one hour because you would use Poppler, and it would be cross-platform. It would also be faster than pdf.js.
You could have done that 20 years ago with COM components already. There was a thriving ecosystem where you could get a component for just about everything.
Similar technologies were available on other platforms than Windows, like Bonobo (Gnome), Kparts (KDE), and whatever Mac had.
It's a bit of a shame that component frameworks have gotten such a bad reputation (for complexity and insecurity), I think they are very misunderstood.
You know where else you could do the exact same thing AND have a 10x faster and 10x more memory/battery efficient editor?
If a native editor just gave you a webview that can run JS extensions...
I wrote a PDF viewer in Java(FX) in about one evening using PDFbox. There are also PDF components for practically any other desktop app framework you care to name, most of them older and more mature than pdf.js
The fact that so many devs express amazement at things considered utterly routine for decades is one of the reasons the entire web dev community is so often treated as a joke.
HTML has very few redeeming features as an app platform. It's way past time it gets killed by something better.
But I do believe there are more people comfortable with web technologies these days.
As far as I can tell I'm actually CPU-limited, because I noticed no real difference from when I had 50 mbps internet. This is on a quad-core Macbook Pro that boosts up to 3.5 GHz...
You not only have to build the code that supports all this, you also have to create and document an API and/or markup format to build all this out, plus document all your internal integration points.
If you want other developers to really take it up and build plugins, you have to make it easy to get into, so that means not just documentation, but great documentation, plus tutorials, examples and tooling to help.
You get a big chunk of that for free when you use HTML/CSS/JS.
Fire up VS Code, go to Help > Toggle Developer Tools, and poke around for a few minutes. Imagine the amount of time it would take to build a similar experience to just this one aspect if you were doing this from scratch.
Don't do it from scratch then. You can use GtkInspector to poke around with any GTK+ application, by pressing Ctrl+Shift+I.[1]
Yes.
> cross platform support
Yes.
> Because you can write plugins in JS?
Yes.
---
As much as I prefer native programs as a user, it's impossible to ignore the benefits of cross-platform development and plebeian hackability/debuggability.
> Yes.
WOW FINALLY SOMETHING that will run on my LINUX and FreeBSD!
ohh.. a lot of plugins don't support linux and it doesn't build on BSD?
Performance & bugs/quirks. I'd much rather have performance.
They all support plugins and extensions, they are all super efficient in CPU usage, etc.
The thing is they aren't new, and because they are all C/C++ codebases developers wanting to add new features to text editors don't want to touch C++98 / ANSI C code from two decades ago.
Then you want to start talking about a C++17 / Go / Rust / etc text editor, but that is starting from scratch, and when you consider the time investment to develop the infrastructure of a text editor today vs just using Electron, the time investment makes less sense for hobbyist devs doing this stuff in their free time.
...is exactly the same. No matter what gui toolkit you use, you still need to develop the infrastructure. Electron doesn't know how to handle keyboard and mouse events, it doesn't have a text buffer implemented, has no understanding of different text encodings, how to parse different languages, and draw different colored text accordingly, or format it, etc.
As I understand it, sublime has tight enough integration with python, such that python can do literally everything you would ever need
I felt the same until I actually tried it out. That changed my mind: now I'll take any platform that those developers & contributors choose for their cross-platform products. Because this for an Electron app, this is a rock-solid 'old-school' (as in, fully as neat smooth helpful-yet-staying-out-of-the-way and somehow "ergonomic" as it was ever since at least oh late 90s, v6 or so) "Visual Studio experience". After a few years of sitting listlessly in front of subjectively inferior editors, I'm prepared & willing to give this Electron stuff more time to further mature improve and speed up. There's no intrinsic reason it can't get there. Lots of seemingly native apps are just live Lua/Python interpreters under the hood with widget bindings in place of a DOM. In that case, well-engineered JavaScript (terribly time-consuming to produce & pretty rare out there for those who like to rely blindly on a huge pile of unscrutinized 3rd-party snippets/script um-I-mean "repos" --- but not impossible) can fully deliver the same, in principle.
Seeing how VScode took off, that could even propel MS to invest unprecedented energies & talent into rounding up the JS "rich client app" performance story further. Who knows.
I don't need x-plat UIs, I just need a good UI toolkit period, and that's why I'm looking real hard at Electron for future desktop work.
I find many of the frustrations people have with desktop Cocoa come from the bizarre need to reinvent the wheel with a custom UI theme. If you stop fighting the system and instead go with a native look with well chosen accents, life is much easier. Native can look great with a little attention to detail.
Half the responses in this thread are people defending the stupid idea of "let's just use js everywhere, just because we can and fuck better suited tools".
Js is not the be all and end all of tools, just because it is used a lot in web doesn't mean it is the best (or appropriate) tool for other spaces.
It sort of seems like js/js ecosystem is built around hacky solutions to things, so I guess it makes sense that the community doesn't seem to see any issue with shoehorning in their language of choice into entirely inappropriate spaces.
Actually there are such editors. I use vim instead of vscode or atom. And I think my installation of vim is slower then vscode because of some plugin that I've not found yet.
Applications like vscode very useful because they help to find performance and other bugs in browsers. Same way as browser improved when gmail and sites like this appeared.
I would support appearance of IDEs, large games, VR, image and video editors in browsers as they help improve web platform.
If you don't like it, just use other option. It could be faster, but may be not. Not sure that vscode is slower then visual studio for most tasks.
They're sexy, they are powerful (extensions for everything), portable, and extremely easy to extend thanks to Javascript being pervasive. I don't know for certain but I'd also assume writing an Electron app is easier than writing a similar app in a lower level language.
Is it really that hard to grasp? Performance has to be perceptible by the average person for it to affect user base. I prefer WebStorm but I've had absolutely no issues using VSCode on my laptop - which feels even faster than WebStorm.
Every dark theme I can find makes the background dark gray, not black. I actually looked into what it would take to make a new color theme and I simply don't understand all the steps, and definitely don't want to deal with the hassle. It very quickly goes off into the weeds of TextMate themes (huh? Why are we referencing a Mac editor? Yeah, I know it's a de facto standard, but really?), editing XML (complete with hex codes for colors) and installing something called "Yo Code". Dude, I just want to change one friggin' color!
In every native app I've ever used, I can just go into the Options and make the background black, period.
Just because it's a programmer's editor shouldn't mean you need to be a programmer to make the simplest configuration.
Better in what way? The market has voted with their downloads, they don't agree that the problems with Electron apps are as bad as you feel that they are.
And I still see native editors used more (for example latest StackOverflow survey, showed that Notepad++, Vim and Sublime combined are used much much more than VScode and Atom combined). I don't want't my editor to crush mid session, or have to write bunch of gulp files and npm commands to do one simple modification.
I agree. However, as someone who has used Visual Studio (the one that costs $$$, not VSCode) which is a native application (AFAIK --- it probably has some .NET and web components too), I can attest to the fact that even native applications can be extremely resource-consuming and slow.
There are plenty of native-application (or JVM/CLR) text editors and IDEs, too. For lots of usage patterns, the browser-engine-based ones have acceptable performance, and the number of people with expertise building for web contributes to the speed of development on those editors and their plugins.
But, sure, if you don't like Electron-based editors, there are plenty of other actively-developed editors for you to choose from.
There's a beautiful poetry to being able to do web dev inside a web application.
I still have Sublime text for when I need to view/edit files with tens of thousands of lines, since Atom chokes on large files, but otherwise I have zero regrets :) I'm as productive in Atom, and it's a more pleasant experience.
I think it'd be better to improve Electron so that native applications don't have so much of an advantage. WebAssembly is a big part of that. Another useful part would be an alternative layout mode that eschews legacy HTML/CSS cruft, for more predictable and performant GUIs.
So I guess it makes sense to optimize for maintainability i this case, i.e. not having one codebase per native OS.
The real reason to me though seems that it's just the easiest way to make a cross-platform UI. And in this web powered world, everyone knows how to code html/css, so why relearn a bunch of new tools?
The lesson here is that our assumed bars of quality for what makes a text editor good are inaccurate. It turns out that the minimum performance bar is lower than you think, and that ease of customization is, in fact, much more important than you think.
I don't care if it's written on to of a browser or in assembly. I just know it's the best text editor I've used so far.
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.
An additional feature is that you can run the IDE in the web browser, so that you can have an online code editor. Think for example about configuration files on the Azure website, or a cloud IDE with multiple people using it.
Honestly I think Visual Studio Code is not slow enough for people to switch. A long web page is very similar to a long code document, all the keywords are just span's with a colour. Furthermore, it is not like Visual Studio or IntelliJ are known for low CPU or smoothness.
Someone just posted some really embarassing benchmark numbers regarding this issue yesterday: 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.
It's very hackable. Just last night I fixed an issue that had been bugging me for a while.
Pages with ads use a lot more of my CPU so I'm not really worried.
This looks like a chrome problem more than Vscode. I do know that they take perf very seriously and this will be given some attention.
I takes "ages" to start up, meaning it interrupts my workflow. I like vscode, but startup time for the app and for new windows is terrible (~2 seconds) and it's one reason why I still prefer sublime for anything that doesn't have significantly better language plugins in vscode.
And I use adblock :)
Because the slowness, when compared to a whole slate of "regular" (== non-web-browser-based) editors, is empirically measurable, and is not just like "twice as slow" or "500% less efficient", but — in many cases, for various operations, as most recently delineated by the joe's own editor benchmarks, but really I mean repeatedly demonstrated over and over for the life of these editors — hundreds of times slower or even infinitely slower (it just gives up and crashes). To a lot of people, that's infuckinsanebro!!!, like a car that gets not n miles per gallon, but needs n gallons per mile.
I get that the extensibility and hackability is appealing. I like that, too.
But at what cost!
VS Code, while slow, has extensions that make me much more productive than when I was using Sublime.
Highlights include:
- auto-formatting my ruby code to fit coding standards. I don't have to spend time mucking with spacing. I write it the fastest way I can, and it fixes it.
- inline git blame. I can easily see who and why a line of code is changed as I select each line. Super useful when debugging. I don't have to kick up the console or fire up github.com in my browser.
- prettify json. I don't have to open up chrome to some json formatting tool to debug my http responses.
edit: I still have to use sublime to open very large files, but that is rare in my work.
Neovim on the other hand is there in a heartbeat, and I do have completion, debugging, linting, file browsing, git integration... available as well :)
> But they have no place in text editing.
Their popularity proves otherwise.
I don't think that's true at all. I have tried both VSCode and Atom, and immediately dropped them both after they crashed opening a file of a few thousand lines.
Sure it uses more memory than nano, but why would I care about that?
For the same reason I don't open log files with Intellij or Visual Studio, I don't open them with VS Code.
I use VS Code as a code editor, not as a text editor. If I want to open a log file, I use Sublime or Vim.
With the latest updates they are now able to open files up to 10Mb, wow.
I was a bit surprised at those tests. It doesn't match my gut feel, VSCode is quite snappy for me.
When it comes to a full featured, modern editor that works quite well out of the box on most modern OSes, I struggle to come up with any answer other than VS Code.
Free, open source, best ide for TypeScript, and better than Eclipse, NetBeans.
Yes it is worth it. I use Atom, which people saying is slower than VS Code, but that's still fine and definitely worth it.
I used to use (and still use sometimes) vim but mostly just Atom with vim-mode-plus plugin.
It is possible to do all that Atom does in Vim and I have colleagues who are very productive with a heavily customised Vim but somehow, despite using it for years, I only ever used quite basic features. Now I can do the things in Atom that I could not bring myself to learn in Vim.
In any case, editor performance is the least of my worries. Most of my time is spent waiting for stuff to deploy and tests to be done, meetings etc. rather than actually writing code. :(
People here are really down on Sublime Text for some reason, but it can actually do everything I need.
IDEs are definitely slower than text editors, but they have their benefits that comes with their tradeoffs (like most things).
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... ;)
Not for 3 billion people. Also energy is not free at all.
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?
"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_.... Qt5 has a fair number too: 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.
It has only been few years since a bug in file copy animation in systray that caused 100% cpu utilization in KDE Plasma 4 has been fixed. It wasnt the first bug in this regard nor it was the last one (IIRC. I saw a similar one in Plasma 5 too, though I didn't check it). Qt is old but cant say it is efficient or optimized. Qt5 programs that use classical QtWidgets have significantly more memory consumption than the programs written in other toolkits, and the newfangled Qt quick widgets is a fucking disaster as can be seen from the aforementioned bug they couldnt even get a simple screen animation straight, so not at all different than Electron ( only few years ahead of them)
Or to put it another way, if you can switch your stack and get a "few years" of progress, that actually sounds amazing.
(Plus, and this applies to Electron too, you're free to fix bugs in open source dependencies that impact your project).
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.
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.
3,540.00 USD to be exact :P ... each year to be exact :P
Workaround:
"editor.cursorBlinking": "solid"Kind of ridiculous that it's so easy to make this mistake.
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.
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)
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.
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
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.
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.
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.
https://blogs.msdn.microsoft.com/oldnewthing/20031010-00/?p=...
I suspect that iPhone's "Clock" app would have difficulties both with smoothness and battery life if constrained to 4MB of RAM and paging...
http://variableghz.com/wp-content/uploads/2012/12/windows-1....
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) while rendering blinking caret in screen of similar complexity (editor with syntax hihglighting):
https://sciter.com/images/sciter-caret-cpu-consumption.png
As you see it CPU consumption is near to zero.
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.
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.
And on an old 8-bit system, blinking a cursor involved toggling one byte (character code) in video RAM. How far we have come...
Sounds like they need to optimize their CSS animations in general.
> 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
Well, apparently the web is built on 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.
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.
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.
The QNX people were really embarrassed about that and fixed the screen saver. We just reconfigured to turn off the display entirely.
https://blog.jetbrains.com/idea/2015/08/experimental-zero-la...
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.
I dislike the implementation of Atom and have been highly critical of it on HN, even crashing a release thread once by pointing out how harebrained it is to implement complex text layout on top of browser APIs when the browser has access to a much richer text shaper itself - we'd know because we wrote it for Qt originally.
Because I've also worked on KDE for 12 years, wrote a big chunk of Plasma 5 and am one of the people porting it to Wayland. We want Wayland for many of the same reasons that make Atom bad, such as state synchronization problems and overhead with X11 (along with its very dire security story).
The intersection you suggest isn't real or doesn't matter. No one working on Wayland uses Atom.
However, just to be pedantic ( ;-) ), I'll have to point out that "a big part of the people defending VSCode in this post agree that X11 is slow" does not imply "a big part of the people agreeing that X11 is slow defend VSCode in this post". The two aren't commutative, since one set of people is quite likely much larger than the other.
Edit:
Oh, and since you mentioned working on Plasma for over a decade: Thank you for making awesome FOSS! :)
So it's a good job we're about to throw it all out and start again, eh folks?
You realize that no X client draws like this nor has for 20 years right? They all use xshm to upload pixels so this "network transparency" is just buffer copying over the network. Not entirely different from a texture upload to a GPU.
> So it's a good job we're about to throw it all out and start again, eh folks?
Yes, by those of us who have been working on the same platform you claim to love, for the better part of a couple decades.
Well, you haven't seen Windows then - the graphics stack is phenomenal and a marvel of engineering. nVidia drivers crash? I only get a second of black screen and then resume my work. Yep, that's right - no other GUI program crashed, I didn't had to do anything, literally just 1 second of black screen.
Oh and you can have one window on two monitors and both parts of window will have full vsync - insane, huh? :)
It's scary how good Windows is.
X11 network transparency was nice feature when 10 mbit ethernet was hot as pizza, but these days remote desktop protocols offer more practical alternative.
Oh God this is why we can't have nice things. How the heck is someone actually justifying this stupid shit here?
As engineers it's our responsibility to not spend our users' resources unnecessarily. This thinking is how we got to the bloated web where pages need a megabyte (or several) of code just to render. Could you imagine an architect saying, "yeah, this design costs 2x that other one, but my clients are rich so it doesn't really matter"? The old saw that "anyone can build a bridge that stands up; it takes an engineer to build a bridge that barely stands up" applies.
I really wish there was a good option for GUI toolkits. Nearly all are either too primitive to make more than freshmen college (or tenured physics professor) level work or asymptotically approach web browsers without all that tedious attention to improvement and accessibility.
But, it is EXTREMELY EASY. There's a reason why Github, Microsoft, Facebook, Adobe etc converged on this decision, and it's not the bandwagon effect. Faced with the same task recently, I did my research, and it is indeed easy.
Since I work on the JVM, my alternative was JavaFX. That didn't seem so bad, but it was much more work. If you look at say IntelliJ IDEA on some platforms, you'll see the text rendering is much uglier than on Atom. Regrettably, if you want to acquire users, that matters more than conservation of resources.
I'm curious: have you ever tried interfacing with X11?
On the other hand, this is 2017, and people apparently don't care much about the footprint of their software, as long as it's convenient and it solves their problem. And ultimately that's what counts I guess.
Consider writing a douglas adams style book
People don't complain that web IDEs are bloated and slow because they need a web browser
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.
(Grace Hopper - Nanoseconds) https://www.youtube.com/watch?v=JEpsKnWZrJ8
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...
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.
/giphy time to burn up ram from everyone in the channelI 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)?
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.
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
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
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
Here's a demo! [4]
Constrain the resources to bring brack some sane levels of efficiency regarding ram/cpu-cycles/hd-space.
/scnr
Is this a MacOS only issue? Does it affect Atom?
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.
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.
I hope when Microsoft fixes this they publish some usage stats and we can see how much energy/money/carbon this will save annually.
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.
I've identified the problem
will-change: opacity
https://medium.com/outsystems-experts/how-to-achieve-60-fps-...
If you use the time you now spend complaining to code instead, you should have the basics covered.
Vim <-- this
I don't think react would do much better, but I will have to try.
I used this template https://github.com/secondtruth/startmin
I noticed that boostrap progress bar is a div,
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.
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.
Without the blinking I lose the file location and have to move it around with "hjkl" so I can find it again.
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.
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?
It seems that these days anything that a developer doesn't care about is seen as "irrelevant geekery".
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.
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.