VS Code uses 13% CPU when idle due to blinking cursor rendering • Hacker News Board

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

#741

Post by rl3 » Fri, Mar 24, 2017, 4:04 PM UTC

rl3 wrote: post #670

boterock wrote: post #643

Earlier quoted context omitted.

On the other hand, connecting a 4k display in windows will default to configure it at 200% scaling, in mac it defaults to render everything tiny as ants.

> ... in mac it defaults to render everything tiny as ants. I'm a fan of no DPI scaling (100%) at 4K, at least on my 27" monitor. It takes 2-3 months of getting used to, but once your brain and eyes adapt, significantly lower dot pitches become completely unusable. The only thing I change is bumping up my terminal or editor's default font size a tad. That said, I'm not sure how people with 24" 4K monitors do it witho…

>...significantly lower dot pitches become completely unusable.

Correction/clarification: significantly higher* dot pitches, as in lower pixel density. "Completely unusable" was meant in the sense of how it'd feel to return to 800x600 after being accustomed to 1080p. 4K is four times 1080p, so it's roughly comparable.

It wasn't my intention to offend anyone with poor eyesight, or suggest that people ruin theirs. Just that it's possible to get used to really low (dense) dot pitches, and once you do it's simultaneously really enjoyable and weird at the same time.

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

#742

Post by digi_owl » Fri, Mar 24, 2017, 4:21 PM UTC

audidude wrote: post #661

fulafel wrote: post #658

Earlier quoted context omitted.

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

Indeed. Especially since TCP-based X would require that you stall operations if you drop a packet so that draw-ordering is preserved.

Could have sworn that there exist multiple takes on extensions for that, but none that has been rolled into Xorg proper. This either because lisencing, or because the current devs have GPU stars in their eyes.

BTW, it is downright funny how just about every Gnome guy i have encountered online seems to come across a pedantic grump. that would not know a joke if it fell on his head...

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

#743

Post by Kiro » Fri, Mar 24, 2017, 4:46 PM UTC

pvg wrote: post #525

Kiro wrote: post #364

Earlier quoted context omitted.

Primarily Sublime Code, Notepad++, PhpStorm and NetBeans.

PhPStorm and NetBeans are not 'native'.

Care to elaborate?

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

#744

Post by Kiro » Fri, Mar 24, 2017, 4:48 PM UTC

ovao wrote: post #479

Kiro wrote: post #364

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

Well, I haven't benchmarked it so it's just how I feel. Maybe there's something in the UX that makes it feel more performant.

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

#745

Post by y4mi » Fri, Mar 24, 2017, 5:23 PM UTC

fs111 wrote: post #360

y4mi wrote: post #233

Earlier quoted context omitted.

tracking or ad scripts by facebook or google are in neither atom nor VSCode. both projects are open source if you care to verify

well, but something similar: https://code.visualstudio.com/docs/supporting/faq#_how-to-di...

you're being asked while installing f you're fine with anonymized usage information being send to MS for further development of the software.

its a simple checkpoint and pretty much every actively developing project does this nowadays.

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

#746

Post by Macha » Fri, Mar 24, 2017, 5:29 PM UTC

flukus wrote: post #614

BHSPitMonkey wrote: post #600

Earlier quoted context omitted.

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.

That varies on the OS/driver/hardware, but IMO, the new AMD graphics drivers being in the kernel tree are the way to go, or something similar like a partnership between MS/AMD/Nvidia. As a consumer it's incredibly frustrating to have a buggy driver and not know who is responsible. Is it MS? Windows comes with a lot of drivers so blaming MS seems fair. Is it the hardware manufacturer? Sometimes you can get the latest…

> then the question is why can't they use the native windows update system?

Cynical answer, and I will grant that gpu vendors are less bad than e.g. printer or smartphone drivers, but it just distributes drivers and so doesn't provide all the opportunities to upsell/advertise to/lock in the users that their bundled crap they can pair with the driver with their own installer allows

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

#747

Post by KirinDave » Fri, Mar 24, 2017, 6:33 PM UTC

problems wrote: post #651

allover wrote: post #552

Earlier quoted context omitted.

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…

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

You know, people say this, but I'd like to push back on it. "Platform native feel" is not something that I think most folks care about. You may need it if you're looking to ship an app for a pay-for-a-copy model, but the vast majority of computing hours people spend are already mitigated by their web browser of choice, and that seems to not really cause any substantial problems.

Electron is a flawed framework for building an app, sure, but you could argue Cocoa or Windows Universal are equally flawed in many ways. They also require a lot more code to get equivalent layouts, are almost never very good at reactively resizing (you may say it doesn't matter, I say I unplug in an external monitor and expect to have something sane happen). The fact that a bug exist causing repeated simple draws to be more expensive than expected is normal for text editors. You can find issues caused by similar problems in Sublime, Emacs, and even Notepad++.

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

#748

Post by KirinDave » Fri, Mar 24, 2017, 6:35 PM UTC

abiox wrote: post #609

stock_toaster wrote: post #559

Earlier quoted context omitted.

"If you learn how to build doghouses, you can build skyscrapers, bridges, and nuclear power plants." Use the right tools for the job. Trying to shoehorn everything into "the web" makes everything just as shitty as the web.

> Use the right tools for the job i wonder if this expression constitutes a thought-terminating cliché.

It does, inasmuch as objective metrics for "correctness" don't exist in our field. The best we can do is show "incorrectness." It's absurd to say, "My tool is correct and therefore should be used," when all we really can demonstrate is, "My tool lacks these specific deficiencies I can identify in another choice."

This bug comes nowhere near demonstrating that Electron or VS Code or Atom are built incorrectly or incorrect tools

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

#749

Post by pcwalton » Fri, Mar 24, 2017, 6:39 PM UTC

kayamon wrote: post #528

pcwalton wrote: post #330

Earlier quoted context omitted.

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…

Win32 was designed around DPI-independence from day one. That's why things like GetSystemMetrics exist. Unfortunately, the app developers chose not to use them. GDI was originally designed to run on printers as well as screens, where the DPI values are completely different. The declarative model of CSS has nothing to do with it. You can specify pixel values in CSS if you like.

> Win32 was designed around DPI-independence from day one. That's why things like GetSystemMetrics exist. Unfortunately, the app developers chose not to use them.

Integer pixel coordinates are right there in the most fundamental functions:

    HWND WINAPI CreateWindow(LPCTSTR lpClassName,
                             LPCTSTR lpWindowName,
                             DWORD dwStyle,
                             int x,
                             int y,
                             int nWidth,
                             int nHeight,
                             HWND hWndParent,
                             HMENU hMenu,
                             HINSTANCE hInstance,
                             LPVOID lpParam);

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

#750

Post by problems » Fri, Mar 24, 2017, 7:05 PM UTC

KirinDave wrote: post #747

problems wrote: post #651

Earlier quoted context omitted.

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…

> 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, You know, people say this, but I'd like to push back on it. "Platform native feel" is not something that I think most folks care about. You may need it if you're looking to ship an app for a pay-for-a-copy model, but the vast majority of computing h…

Maybe it's just me, but I always avoid apps that don't integrate well with my platform. They're just not pleasant to use. I want the same look and feel, I want the same file browser, I want the same DPI scaling my desktop uses and I want the same UI standards followed, not some giant mess of whatever every individual dev decides seems nice that day.

I'm not so sure it's mitigated by the web - people may browse Facebook and a few news sites, but those aren't complex applications at all and they have very simplistic UIs that don't attempt to imitate familiar desktop controls or to show desktop concepts like files and folders.

I have far more problems with Electron app sizing than I do with proper desktop apps - see my examples above.