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

651–660 of 801 posts

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

#651

Post by problems »

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.

If you're meaning to say you can write "multi-platform desktop" apps using Electron... I suppose you're technically correct, but they don't feel native on any platform, are generally slow, massive to distribute, don't integrate well with other applications and generally have weird non-native-app-like behavior. Like Discord I can resize and have the minimize/maximize/close buttons overlap the window. Atom and VS Code still can't do DPI scaling right. I wouldn't say you can build good desktop apps with them. Just crappy little ones. Maybe that's necessary to interact with one library or another, but that's a tradeoff. And a big and important one to recognize.

Maybe React Native will work on desktop and fix all this eventually, but IMO React Native is just not there yet, it doesn't even feel native on mobile.

I say this as someone who writes both an app with both an Electron/React portion (in order mainly to interact with a specific JS library) and a Qt portion. I really do like the way React does a lot of things and npm seems like the exact right way to do package management in a programming language - but the JS ecosystem is a mess. While I'll agree the wealth of developers on it has had many good results, it's also created a horrible moving target. There are half at least 5 different and fairly popular module systems, module loaders, etc. There are constant attempts to use language features which aren't official yet or even at a final spec via babel. The build and packing systems are a mess, everyone has their own different series they prefer and getting working integration between a few can be problematic.

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

#652

Post by _sh »

eltoozero wrote: post #449
Zenst wrote: post #361

Earlier quoted context omitted.

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…

SMIT running man example: https://www.youtube.com/watch?v=YMWSD69BWqI If anyone knows where I can get those animation frames, I'd like them for a personal project as a "running" indicator.

Dr Racket has something similar.

http://soegaard.github.io/blog/2013/06/21/running-man/

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

#653

Post by Neeek »

ReverseCold wrote: post #650
Neeek wrote: post #644

Earlier quoted context omitted.

I think it's only 150%, currently running windows on a 28" 4k monitor makes me think 200% would be too much? Oh I should also add that I haven't ever had any of the DPI issues the parent's parent is referencing. The only problem with multiple display DPI in Windows 10 is the shockingly bad fuzz you get on your secondary display from the thing being rendered either smaller or larger than normal (depending on whether t…

It may somehow be detecting the size of the display. My 13" laptop likes 250% scaling, while my 27" monitor likes 150%.

That would make sense, your DPI scaling is all to do with readability after all :)

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

#654

Post by DigitalJack »

klibertp wrote: post #568
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.

It's not "Emacs" itself, it's plugins and Elisp libraries you have loaded. Emacs itself - the GUI, even including (optionally) blinking cursor - is actually quite fast. To prove this, this command: time emacs -Q --eval "(kill-emacs)" reports ~0.2 sec on my system. My normal Emacs, just as yours, needs ~12 seconds to start up. But I made it this way by explicitly enabling and requiring things. I could, with some effor…

Yes, this is true. But emacs without plugins isn't worth much, and I'm too old to enjoy playing the configuration fiddle for more than a few minutes

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

#655

Post by Neeek »

bitexploder wrote: post #596
ldev wrote: post #555

Earlier quoted context omitted.

> X11 runs really well these days -- responsive, fast, reliable Well, you haven't seen Windows then - the graphics stack is phenomenal and a marvel of engineering. nVidia drivers crash? I only get a second of black screen and then resume my work. Yep, that's right - no other GUI program crashed, I didn't had to do anything, literally just 1 second of black screen. Oh and you can have one window on two monitors and bo…

FWIW my graphics drivers crashes on Ubuntu always recover. Even a complete GPU hang. It sees the driver is hung and restarts it causing a few seconds of minor glitching. Configuring X is not for the faint of heart, but in Unity it is basically magical and deals with HiDPI displays, etc. just fine. Feature for feature it is very similar to Win or Mac on the display and GPU driver front. The total package still feels r…

My only issue with configuring X is that 'load "glx"' will not fetch the correct libglx.so with nvidia drivers loaded unless you tell it to go looking in /usr/lib/nvidia-[VERSION]/ :| took me a very very long time to get GLX working on my setup.

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

#656

Post by fulafel »

tetromino_ wrote: post #554
zbuf wrote: post #534

Earlier quoted context omitted.

Best bit is that X11 runs really well these days -- responsive, fast, reliable. Emacs runs great, gitk, xterm, xosview, mplayer window manager, even Firefox is alright. Renoise, Maya, Blender too. Not to mention network transparency when I need it. It's a great environment to get my work done, and 3x hi res displays is the stuff I dreamt of 15 years ago. So it's a good job we're about to throw it all out and start ag…

If by "responsive, fast, reliable" you mean awful screen tearing when you mix X11, OpenGL, and/or video playback. Fixing it on any given machine is often possible through some voodoo and a hand-rolled combination of driver and software settings, but that voodoo works only for one specific combination of hardware and driver version, and every update means more rounds of trial and error...

This is not because of X11 the protocol though, just implementation bugs. Thus not a good reason to start from scratch.

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

#657

Post by smitherfield »

abiox wrote: post #619
smitherfield wrote: post #563

Earlier quoted context omitted.

Yes, I know why it's the case nowadays: at my work, for example, I occasionally touch all the major areas of modern software development — server backends, mobile, Javascript-in-the-browser and meta-software for writing software — but I've never done what the average person, and maybe even I, would think of when they hear the term "software development." And it does seem very very strange. I'm imagining this Socratic…

>Socrates: OK! So could you show me a real application then? Like, it says "Hello, world!" in a window, with a menu and buttons and stuff? And it will be the same on both Windows and Linux? >Developer: No, that's not possible. swing? awt? javafx?

I exaggerate somewhat, but all three are low-quality and further development appears to be abandoned.

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

#658

Post by fulafel »

audidude wrote: post #617
zbuf wrote: post #608

Earlier quoted context omitted.

> You realize that no X client draws like this nor has for 20 years right? They all use xshm to upload pixels [...] You seem to be misinformed. Of the applications I mentioned, the main ones (gitk, xterm, emacs, xosview) are not doing that; seen clearly by analysing the X traffic. Of course, some of these could be built with an optional Qt front-end, in which case I would not be surprised. So you stated clearly "all"…

That's precisely why I stated 20 years. Those programs were written before that and largely haven't changed since. If you wan't anti-aliasing in any of those above (gitk/emacs come to mind) you'll be doing client side rendering of fonts and copying pixels.

"Copying pixels" is the dominant mode of operation in other remote GUI protocols like RDP, so it's not the end of the world.

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

#659

Post by [deleted] »

BHSPitMonkey wrote: post #600
flukus wrote: post #595

Earlier quoted context omitted.

I think that's a case of necessity being the mother of invention. IME the windows 10 drivers crash much more frequently than the linux or windows 7 ones ever did.

I don't think it's fair to blame the OS for driver crashes. Those are a result of third parties and can happen on any platform.

[deleted]

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

#660

Post by audidude »

aidenn0 wrote: post #648
audidude wrote: post #578

Earlier quoted context omitted.

How have you managed to make an argument about embedding a web browser about GNOME? As it were, GNOME's IDE (which I wrote) uses 0% CPU at idle.

To be fair, the conversation had already shifted to X11/Wayland. GNOME does have a history of starting over from scratch every few years; you probably had a good reason for writing Builder instead of working on Anjuta, and that's just the way the GNOME community seems to do things. This makes people, especially power users, disproportionately angry because when you rewrite something, it will be different (that's sort…

> GNOME does have a history of starting over from scratch every few years;

The GNOME project will be 20 years old in a couple of months. So while it might feel like "every few years", we really don't change direction all that often.

As you can imagine, those that show up to do work have a great deal of say in where the project goes.

> you probably had a good reason for writing Builder instead of working on Anjuta, and that's just the way the GNOME community seems to do things.

> This makes people, especially power users, disproportionately angry because when you rewrite something

You've sort of made my argument for not changing Anjuta over the years. We knew the amount of stuff that had to be changed would leave both the code-base and UI looking very little like Anjuta. Best to let people continue using it in the mean time.

> (I still cry a little inside any time I remember Galeon.

It lives on as Epiphany and is the primary driver of the WebKitGtk backend.

Post reply on HN