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

311–320 of 801 posts

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

#311

Post by lispm »

gmfawcett wrote: post #302
pantulis wrote: post #272

Earlier quoted context omitted.

Which begs the nice corollary: the definition of "native" doesn't happen to be fixed and changes with time.

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.

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

#312

Post by criddell »

JustSomeNobody wrote: post #144
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.

Where are the Michael Abrash's of today teaching people how to write tight, fast code? Seems a lost art... Yes, I know, he's still around...

Except today's machine language is javascript.

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

#313

Post by eeZah7Ux »

dahart wrote: post #293
ChuckMcM wrote: post #70

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

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…

> cpu time & memory are close to free

Not for 3 billion people. Also energy is not free at all.

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

#314

Post by ryanpepper »

mbel wrote: post #166
Spivak wrote: post #117

Earlier quoted context omitted.

And yet that hacked together document rendering engine manages to be less painful to use than the the current show of UI toolkits. 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.

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

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

#315

Post by kardashev »

jstarks wrote: post #274
kardashev wrote: post #268

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…

What hardware or operating system changes do you think are necessary to improve the GUI development experience?

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.

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

#317

Post by criddell »

mercer wrote: post #220
dheera wrote: post #186

Earlier quoted context omitted.

> there's a networked file system > a multi-user collaboration engine > a realtime notification system None of these apply to a new, unshared document. Those subsystems can be loaded slowly over the following 10 seconds, that's fine. Is it such a hard thing to ask to make the UI responsive within 0.1 s? Like, be able to type stuff and have it appear on the screen without delay? It's so bad that I often use the basic…

Over the past year or two Gmail has gotten really slow. I'm not sure what happened, because there are no new features I can think of that would cause this. It's gotten so bad that I'm considering moving to another provider or using a good old email app again.

I've noticed that too! Do you use Inbox? I do and I was thinking about going back to the classic interface to see if it's faster.

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

#318

Post by dragonwriter »

8draco8 wrote: post #183
abritinthebay wrote: post #151

Earlier quoted context omitted.

VS Code is faster than Atom (by... a lot) tho? Especially with large files, but just in general. Speed is the main reason I can't stay using Atom for more than a few hours. It's awful. VS Code is snappier than Sublime Text ffs...

VSC is not even close of being as snappy as Sublime Text. Sublime also dominates when opening large files (2GB+) and searching trough them.

While I occasionally need to open large files like that, they aren't source code files, and I have no problem using a different tool than my main source editor for that.

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

#319

Post by pcwalton »

yumaikas wrote: post #291
dvdcxn wrote: post #160

Earlier quoted context omitted.

I don't get this criticism. HTML/CSS is the closest we have to a universally understood syntax for designing interfaces. 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 th…

HTML and CSS are a bad fit for rendering heavy graphical interfaces because they fundamentally follow a document flow rather than grid-based layouts. Flexbox and css-grid are helping some in this area, but they are not used very often. (not to say that HTML and CSS aren't useful, but they are far from the idea means of rendering a UI). HTML does work fine when you use it for mostly document focused work, and I enjoy…

Flexbox is that improvement.

If you discount flexbox due to "not [being] used very often", then you can't logically argue for burning down the HTML and CSS stack and replacing it with something else that has zero market share.

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

#320

Post by veidr »

itake wrote: post #301
veidr wrote: post #275

Earlier quoted context omitted.

> I don't know why you're saying they are slow 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…

have you used VS code? I recently switched from Sublime to VS Code. Originally, I hated the slowness. But the slow point in my work (Software engineer) is not how fast I open files, but on how easy is it for me to transfer what I am thinking to the screen. 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 codi…

Yeah, I have, and I actually use it regularly (along with several other editors). The slowness (of not just opening files, but editing them) drives me up the wall, but in certain workflows (e.g., TypeScript) it can be worth it.
Post reply on HN