Crossing my fingers any related changes don't kill the cursor in the vim extension. Maybe I'll skip the next few updates...
Hey bud, I am here for you as a developer of the vscodevim extension. I will make sure it works just for you.
VS Code uses 13% CPU when idle due to blinking cursor rendering
541–550 of 801 posts
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#542Earlier quoted context omitted.
Please don't. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newswelcome.html We detached this subthread from https://news.ycombinator.com/item?id=13940554 and marked it off-topic.
There might be an insult or two thrown around but detaching the thread removes necessary context. I do not think that this was the appropriate course of moderation.
It was uncivil, unsubstantive, dismissive of others' work, broke the HN guideline against using uppercase for emphasis, took the thread into a programming language flamewar... Please just don't post like that to HN.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#543An internet points out that Hackernews' favorite text editor takes up more CPU than the average Hackernews would have had at their disposal 20 years ago just to make the cursor blink on and off. Hackernews circles the wagons to justify the stupid engineering design decisions behind said editor based solely on the fact that embedding a complete Web browser just to draw buttons and text fields "won" over any sensible G…
Love your meta comment
Consider writing a douglas adams style book
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#544Earlier 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.
Outlook.com as well. When it launched, it was blazingly fast. Now it comes with a loading screen and really laggy.
Bloated single page apps is the curse of the modern web.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#545Earlier quoted context omitted.
The only ever time I see performance issues is when I accidentally click on a binary by accident. Atom's large file handling is awful... But how often do you open a 100MB text file?
When I'm looking at trace files to figure out why an error occurred, I'm happy when I only get a 100MB one to look at.
I'd always jump to something like (unix) `less` to do something like that. I don't see it as a failure of my main programming 'text editor' that it can't open log files, because I wouldn't even try that in Vim (which I'm also very comfortable with).
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#546Earlier quoted context omitted.
This might mark the first time in history that Emacs was trotted out as an example of a performant editor. I say this as an Emacs user.
Emacs takes 8-15 seconds to open on my new i7. That matters when I just want to do quick edits. Vscode takes 3.
There is something wrong with your system.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#547Earlier quoted context omitted.
> On Win32[0], the blinking caret can be shown anywhere inside a window, not just on a text field. (...) I'm sure other operating systems have this kind of facility - after all, how does the built in text edit control draw its caret? The "built in text edit control" IS a native text field already.
My point is that the built-in text edit control needs some way to draw it's caret, so surely a universal method to draw a blinking caret exists somewhere.
I'm not aware of any system where one can create that caret without a text edit control to hold it. That means that, if the standard text edit control isn't suited for what you want to do, you can't have the caret.
Certainly, on the original Mac OS (a system on which I worked on OS patches for detecting the location of the caret) the method that application used for drawing the caret varied widely. I've seen it implemented by drawing a line, by drawing a rectangle, either in one go or in two parts (that happened in applications that supported a split caret, even if the caret wasn't split), with various transfer modes. Slanted carets typically were application-specific, too.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#548Earlier quoted context omitted.
Primarily Sublime Code, Notepad++, PhpStorm and NetBeans.
That's an unusual experience. Based on a handful of benchmarks[0] done by the author of JOE, VS Code is sometimes an order of magnitude slower than Notepad++ and Sublime at some tasks. I use VS Code pretty much exclusively these days myself, so I'm not picking on it by any means. [0]: https://github.com/jhallen/joes-sandbox/tree/master/editor-p...
I have the same experience on my pretty slow laptop. Granted, my projects aren't big, but I would take vs code over sublime any day. Interestingly, atom feels much slower compared to both.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#549An internet points out that Hackernews' favorite text editor takes up more CPU than the average Hackernews would have had at their disposal 20 years ago just to make the cursor blink on and off. Hackernews circles the wagons to justify the stupid engineering design decisions behind said editor based solely on the fact that embedding a complete Web browser just to draw buttons and text fields "won" over any sensible G…
I'm glad at least we made fun of both sides. 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.
Seconding Qt, there's a bunch of bindings for non-C++ languages as well. It hits the uncanny valley sometimes but overall it's much better than the alternatives (like WxWidgets).
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#550I'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…
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…
It's fairly regular in my field (game dev) to put some debugging/instrumentation code in and only enable it for one frame after a key is pressed.