Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

581–590 of 801 posts

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

#581

Post by kazinator »

gmfawcett wrote: post #538
lispm wrote: post #366

Earlier quoted context omitted.

The Lisp code is not natively executed. Some features like memory management (garbage collection) are layered on top of the OS. The UI is not 'native' - it's based on a portable substrate written in C/Lisp, which works both on WIMP and terminal systems. The user interaction is not native (commands, buffers, undo, preference dialogs, window/frames, ...). etc.etc.

I never said the Lisp code was natively executed. I'm not sure where you got that idea. Let's just agree to disagree. We are talking past each other at this point. Best regards!

I think that the definition of "native" should take into account how the code interacts with the system.

Because compiling code to the native instruction set shouldn't affect the semantics: so why should that be the only yard-stick for "native", right?

What is semantically relevant is: how much of the platform is exposed to the programs directly, versus through abstractions.

Suppose a language like Emacs Lisp or Java or whatever has only thin wrappers around POSIX through which applications interact with the platform. Then those programs are quasi-native POSIX programs, really. They are doing things like fork, waitpid, dup2 and whatever almost directly. And suppose that in the Windows version of that language, programs use functions that mimic CreateProcess or WaitForSingleObject. Then, regardless of the language being interpreted, it's really a native programming language.

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

#582

Post by pjmlp »

kayamon wrote: post #529
pjmlp wrote: post #414

Earlier quoted context omitted.

That is not true, before DirectX there was WinG and there were quite a few good games done in WinG. The lack of games was mostly due to reluctance of game developers to abandon Assembly and using directly PC hardware, specially because C and C++ compilers were "too slow".

WinG didn't come around until 1994 though. If you wanted to ship a game in 1990, you had a choice of using GDI or using MS-DOS. And the "assembly" argument doesn't make any sense. You can program Windows games in assembly if you want.

Windows only became relevant for home users after version 3.0, actually the 3.1, which was released in 1992, so of course no one was shipping Windows games in 1990!

Sure you can use Assembly on Windows and there were a few books teaching exactly that, but you weren't allowed to touch the graphics hardware any more, unless you were doing a graphics driver, and do all those graphic card tricks, specially mode X.

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

#583

Post by biggiesmalls »

paulirish wrote: post #244
Touche wrote: post #41

Earlier quoted context omitted.

I think I don't understand the issue well enough. This looks like a standard blinking cursor to me. Users expect a blinking cursor in an editable text field. I'm not sure why this implementation is slow or why they needed to implement it themselves and not let the OS handle the blinking cursor. I'm guessing there must be some reason.

Powerful* text editors built on the web stack cannot rely on the OS text caret and have to provide their own. In this case, VSCode is probably using the most reasonable approach to blinking a cursor: a `step` timing-function with a CSS keyframe animation. This tells the browser to only change the opacity every 500ms. Meanwhile, Chrome hasn't yet optimised this completely yet, hence http://crbug.com/361587 . So curren…

>> text editors built on the web stack cannot rely on the OS text caret

Can you explain in simple terms why this is the case? Why on earth not?

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

#584

Post by FridgeSeal »

tomc1985 wrote: post #68
Philipp__ wrote: post #14

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…

The current state of Javascript is very much, "just because you can, doesn't mean you should"

For sure.

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.

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

#585

Post by StreakyCobra »

coldtea wrote: post #514
StreakyCobra wrote: post #271

Earlier quoted context omitted.

> 10x faster and 10x more memory/battery efficient editor? Except for the startup time --- with which I can live with --- I never felt a difference in speed between native text editors ans VSCode. There is one, but I don't notice it. Human are much more slower than computers, so as long as it is not taking more time that I need to notice it, I don't care. Nowadays my computer has enough memory so I can afford to not…

> Except for the startup time --- with which I can live with --- I never felt a difference in speed between native text editors and VSCode. There is one, but I don't notice Try editing anything larger than a simple program file (from a large JSON to a CSV as devs often do) and you'll do. Try hex editing a large binary. And many other tasks.

Sooner this evening I had to open a 144'000 lines CSV file, 3.5MB. This is not big, but it is the kind of file I have to open from time to time for my work. No noticeable delay to open the file in VSCode, the cursor moves smoothly, and scrolling with the minimap through the whole 144'000 lines is also smooth. The VIM plugin for VSCode start to have troubles over 10M it seems, but if I have to edit files bigger than this I can open them with spacemacs anyway. I spend most of my time in small text files like Python, CSV or Makfiles, so this is not a problem. Of course if you have other requirements, like you are passing a lot of time in big files, then VSCode is not the correct tool.

I would suggest you to try VSCode for curiosity, if you have not done it yet. You could be surprised. Maybe it is not the right tool for you, but it is quite well made, and compared to atom, bracket or other web-based text editor, it feels like a supersonic jet.

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

#586

Post by pjmlp »

brilliantcode wrote: post #18
Philipp__ wrote: post #14

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…

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…

> Even the end result UI design look & feel is butt ugly.

Only when developed by those devs that never bothered to read books like "Filthy Rich Clients".

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

#587

Post by reitanqild »

allover wrote: post #552
problems wrote: post #531

Earlier quoted context omitted.

Qt pretty much nails this balance, WPF isn't bad either. Both will run circles around browsers at rendering performance and are much less tedious to develop in unless you've only done web dev before.

If you learn React, you can write for web, multi-platform desktop and (native) mobile, with React Native. Same can't be said for Qt or WPF. Also the Qt community is minute compared to the JS community, that is significant.

As someone who maintain other peoples code I really don't look forward to deal with js a few years from now:

What build system did they use?

Where is that package? Does it even exist anymore.

Etc.

Had similar problems trying to maintain a delphi project as an almost fresh from scool developer. At that point I understood the value of Java and Maven.

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

#588

Post by pjmlp »

ryanpepper wrote: post #314
mbel wrote: post #166

Earlier quoted context omitted.

> I think we'll get there eventually but until a native toolkit presents an interface as easy to use as the web developers are going to take the path of least resistance. Like Qt did with QML? http://doc.qt.io/qt-5/qml-tutorial1.html

Yeah, but Qt has licensing costs for commercial use...

Oh, lets be professionals and not pay for our tools like everyone else does, who needs money anyway!

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

#589

Post by fapjacks »

m-p-3 wrote: post #420
jcwayne wrote: post #338

Earlier quoted context omitted.

In the early days of working on my current main project, I found that updating a progress bar was slowing the process it was monitoring. Since there were times when it was useful to see near real-time progress, I added added a slider which allows the user to adjust the sampling rate. That slider is affectionately known (by me anyway) as the Heisenberg Compensator. P.S. I have sped up my shit. That process originally…

> Heisenberg Compensator That's a perfect name, I love it.

There's a Heisenberg Compensator in Star Trek transporters [0]

[0] http://www.startrek.com/database_article/heisenberg-compensa...

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

#590

Post by JdeBP »

koolba wrote: post #87
Philipp__ wrote: post #14

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…

Because if we don't build it inside a web browser, we'll have to add plugin support to add a web browser inside of it. Then you have two problems.

Actually then, in accordance with Zawinski's Law, one will be able to use that web browser to read mail. (-:
Post reply on HN