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

321–330 of 801 posts

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

#321

Post by lorenzfx »

StreakyCobra wrote: post #168
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…

By making a text editor out of web technologies, you can reuse all the web ecosystem the web has, and enjoy also its customizability. 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…

I don't think this would have been any harder had it been written in C(++) for someone comfortable in C(++).

But I do believe there are more people comfortable with web technologies these days.

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

#322

Post by tomc1985 »

oblio wrote: post #309
tomc1985 wrote: post #290

Earlier quoted context omitted.

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?

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.

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?

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

#323

Post by pcwalton »

ksk wrote: post #305
dvdcxn wrote: post #177

Earlier quoted context omitted.

Care to argue why? Also, there are countless alternative languages to compile down to HTML or CSS available. Feel free to create your own if none agree with your personal leanings.

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 immediate mode. It redoes layout from scratch every frame.

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

#324

Post by ptaipale »

digi_owl wrote: post #250
braveo wrote: post #167

Earlier quoted context omitted.

I've actually witnessed a very large oil & gas company switch over from those old dos programs to a new win32 program, and to a man, every person who had any experience on the old system bitched about how much slower it was to get anything done. Having worked on the system myself, they were right (this was as a noobie to both systems). There is something to be said for a small, tight system.

Some time ago HN linked to a blog from a Norwegian tasked with mailing 3.5" floppies to doctors. This because the doctors insisted on using a DOS based patient journal, as they could operate it completely by keyboard while maintaining a conversation with the patient. I speculate that one reason for this is that DOS allowed each program to have full keyboard access, while Windows and other GUI has to reserve certain k…

You don't need the Windows reserved keys for anything with an application. You could make a fully keyboard operable UI for an application on Windows.

It's just that software makers don't do it; most everyone thinks everyone loves to do things with mouse et al.

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

#325

Post by gmfawcett »

lispm wrote: post #307
gmfawcett wrote: post #165

Earlier quoted context omitted.

Most of those jokes are completely out of date. "Eight Megs and Constantly Swapping" used to be a big deal, but today it's not. I don't think running Elisp in Emacs takes away from it being "native." At least insofar as there are no popular text editors (that I know of!) which expect you to compile your plugins and macros to native code. They all have interpreters of one kind or another. What Emacs doesn't have, thou…

GNU Emacs Lisp code is certainly not native - not until a JIT will be widespread. GNU Emacs usually compiles Lisp code to a byte code which is interpreted by a byte code engine written in C. If you use a Common Lisp based editor like Clozure CL, Allegro CL and LispWorks have, they don't use a C-based byte code interpreted. The Lisp code is compiled directly to native code. Which makes editor extensions running in nat…

I should be more clear. I don't think that just because Emacs contains an Elisp interpreter, we should call it a "non-native" application -- even if Elisp is integral to Emacs' operation.

If forced, I would say that Emacs-the-platform is native, and Emacs the system of Editor MACroS is not, since the macros run on the Emacs platform. But it seems kind of pedantic.

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

#326

Post by forgotpwtomain »

digi_owl wrote: post #250
braveo wrote: post #167

Earlier quoted context omitted.

I've actually witnessed a very large oil & gas company switch over from those old dos programs to a new win32 program, and to a man, every person who had any experience on the old system bitched about how much slower it was to get anything done. Having worked on the system myself, they were right (this was as a noobie to both systems). There is something to be said for a small, tight system.

Some time ago HN linked to a blog from a Norwegian tasked with mailing 3.5" floppies to doctors. This because the doctors insisted on using a DOS based patient journal, as they could operate it completely by keyboard while maintaining a conversation with the patient. I speculate that one reason for this is that DOS allowed each program to have full keyboard access, while Windows and other GUI has to reserve certain k…

Do you happen to have the link to this blog handy? I'd be interested in reading it.

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

#327

Post by DigitalJack »

packetslave wrote: post #201
DigitalJack wrote: post #98

Earlier quoted context omitted.

Emacs takes 8-15 seconds to open on my new i7. That matters when I just want to do quick edits. Vscode takes 3.

export EDITOR="emacsclient -a ''"

Unfortunately the group of plugins I use combined with running in windows just isn't stable enough to keep a server process running.

Admittedly this is a corporate laptop with all their virus crap running, so no editor is fast. But emacs in particular has very bad startup times for me.

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

#328

Post by dragonwriter »

TeMPOraL wrote: post #78
brilliantcode wrote: post #18

Earlier quoted context omitted.

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…

Swing was at least meant to do UI. Web stack is not ; webapps are essentially a pile of ugly hacks on top of a document rendering engine, and it really, really shows - especially when you have webapps pretending to be native (e.g. webview-based apps on mobile). Also, for Java there's JavaFX (a de-facto standard UI toolkit for Java), which is very nice to work with.

> Swing was at least meant to do UI. Web stack is not;

The ancient history of the web, clearly, is different, but the modern web stack, both in terms of specs (WHATWG HTML/W3C HTML5 and related standards) and modern browsers are very much engineered for applications, not just classic documents, as a primary use case.

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

#329

Post by gmfawcett »

lispm wrote: post #311
gmfawcett wrote: post #302

Earlier quoted context omitted.

Well, language is like that. :) But I don't think describing Emacs as "native" here is very different from how the word was used decades ago. To me, "native" is less about how the logic is represented (compiled vs. interpreted code) and more about its execution context. If the host system is an operating system, then the application is native; if the host system is another application, then it's not. I agree that the…

GNU Emacs comes with its own portable execution platform (the byte-code Lisp execution engine), where Java applications typically use a provided virtual machine. As such GNU Emacs is just as 'non-native' as a JVM-based editor.

Almost agree with you! If the Emacs VM were used for applications other than Emacs -- if it were a general purpose VM -- then I'd completely agree.

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

#330

Post by pcwalton »

gvb wrote: post #253
thechao wrote: post #129

Earlier quoted context omitted.

Except that the abstraction layer for the user has remained the same. The extra abstraction layers you're talking about are invisible to the user... while our GUIs are slower, and our processors faster. It feels like, after 30 years, we should be able to have our GUI cake and eat it, too.

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 declarative model of CSS.
Post reply on HN