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, whe…
VS Code uses 13% CPU when idle due to blinking cursor rendering
391–400 of 801 posts
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#392Earlier quoted context omitted.
You can do it, but it's significantly harder. And with Electron, you can leverage the same skills that are used to build web applications to modify your environment and text editor as well. Those are very significant advantages. Note: I don't use VS Code or any other JS editor, I use emacs. But I can definitely appreciate the major benefits of the architecture.
So does it have a NoScript plugin to kill the unavoidable 200 tracking and ad scripts from Google, Facebook and who knows what running in the background? I am sorry if I offend someone with this, however the current Web experience is something I want as far away from my dev. tools as possible.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#393Earlier quoted context omitted.
How fast does it run on 1995 hardware though?
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.
http://variableghz.com/wp-content/uploads/2012/12/windows-1....
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#394Earlier quoted context omitted.
Isn't this a false dichotomy? Why not create more modern, declarative native APIs and libraries, or use them where they already exist?
Because it's less effort and more likely to be successful to just improve Web implementations.
Edit: I'll add, I frequently see people say that Windows XP was the best OS ever made. Why the rose-tinted glasses? It was the tail end of the era when hardware was getting faster, faster than software was getting slower.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#395I'm reminded of this classic: https://github.com/npm/npm/issues/11283 NPM had a progress bar that was so fancy that it slowed down installation time (basically its only job) by ~50%. Hilarious. My mantra here is, if you find yourself thinking about implementing a fancy loading spinner/progress bar, it would be more productive to just spend that time making it unnecessary - speed up your shit! Obviously that doesn't a…
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.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#396Earlier quoted context omitted.
The abstraction layer has only remained the same visually, and only for a loose definition of "visually." In the "good old days" the user interface was 640px x 480px (original VGA[1], skipping past the original MDA, CGA, and Hercules graphics cards[2] since they predated "modern" GUIs). Then it was expanded to 800x600, etc. The programs of those days were hard-coded to the graphics adapter resolution. If a program di…
Precisely. And even Win32, which is being touted in this thread as somehow far superior to the Web stack, was never designed for high DPI apps. It's far worse than the Web stack, with exact pixel hardcoding everywhere. That's why the HiDPI situation on Windows is such an inconsistent mess. Meanwhile, the Web scaled up to HiDPI so seamlessly that most people never even noticed any friction. This is the benefit of the…
CSS people still think a grid is a choice of "small" "medium" and "large" columns/rows. Haha.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#397It 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, whe…
the benchmark you linked is outdated, I reran those tests just now with vscode and could perform all open, edit, close operations in the test in fewer than 2s.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#398I'm reminded of this classic: https://github.com/npm/npm/issues/11283 NPM had a progress bar that was so fancy that it slowed down installation time (basically its only job) by ~50%. Hilarious. My mantra here is, if you find yourself thinking about implementing a fancy loading spinner/progress bar, it would be more productive to just spend that time making it unnecessary - speed up your shit! Obviously that doesn't a…
IBM spent a humongous amount of man hours upon the running man in smit under AIX, many of those consumed with making sure it ran correctly on all systems of various speeds without the animations going crazy. Alas I don't have exact man hours, but that was what one of the engineers told me a nearly 2 decades ago now. Hopefully somebody else has more detail upon this as one of the earliest examples of progress animatio…
I have often wondered since why this was not a more popular way to deal with long running installers.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#399Earlier quoted context omitted.
Do you want to listen to the reasons, or just tell them to "go make your own if you don't like it"? You can't have it both ways. I agree that simply saying X sucks is not a valid argument. Howeever with CSS/HTML the flaws are too numerous and already discussed ad nauseam over the past 15 years. Everytime a new version of CSS comes out, people go and try it and find out that it sucks, whether its th broken box model o…
> Which also explains why there isn't even a reference implementation. As someone who has spent years implementing those standards, a reference implementation would not help me at all. > As far as UI layout is concerned I am fairly sure I could out-compete a web developer in terms of time taken to implement, using something like IMGUI. Dear imgui's layout model doesn't scale at all, due to the fact that it's immediat…
I don't quite understand what you meant your comment to be indicative of. That nobody else would consider it useful? That you personally see no value in reference implementations at all?
>Dear imgui's layout model doesn't scale at all, due to the fact that it's immediate mode. It redoes layout from scratch every frame.
Could you detail the UI are you thinking of where IMGUI is inefficient but HTML/CSS isn't? Not asking for a formal spec, just a general usecase..
My problem with CSS/HTML is that productivity scales inversely when using them.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#400Earlier quoted context omitted.
> You both do realize that similar arguments could have been made back in the day when moving from, say, command-line DOS applications to Windows API applications - right? No, we don't. With Windows API there's no sandbox and extra embedded language overhead (it's still native code like in DOS, and even optimized better, able to use more available memory than DOS would allow, etc.). Oh, and you also got the benefit o…
> Not to mention that the Windows API UI toolkit, while bad, is sane compared to the web stack. Completely disagree. Charles Petzold's HELLO.C is hundreds of lines of code. Hello World on the Web is, well, "Hello world!". "Sane" environments don't force you to make up a distinction between "long pointers" and "pointers" if you want to conform to the house style in order to match 16-bit x86 real mode. Or route all eve…