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

#641

Post by userbinator » Fri, Mar 24, 2017, 3:43 AM UTC

MichaelGG wrote: post #284

antisthenes wrote: post #237

Earlier quoted context omitted.

Excel loads in ~1 second...and doesn't have UI lag after it does. Try working with large data sets in Google Docs and you'll have that 2-3 second lag time with _every_ operation you perform.

On the flip side, the new Windows "Metro" style calculator app takes several seconds to load ... and is less usable than the old calc.exe.

IMHO calc.exe has been getting worse since XP:

https://news.ycombinator.com/item?id=10791667

(Note that the "Calculator Plus" mentioned there has --- not suprisingly(!?) --- disappeared from Microsoft's download center, but you can still find the official, signed installer by searching for "CalcPlus.msi".)

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

#642

Post by userbinator » Fri, Mar 24, 2017, 3:46 AM UTC

sfifs wrote: post #225

dheera wrote: post #40

Earlier quoted context omitted.

Yep. I also can't wrap my head around the fact that we are now constructing buttons, drop-down boxes, tagged text boxes using dozens of nested layers instead of a native widget that writes directly to the screen. My 486 rendered UIs with nearly imperceptible lag. Google Docs takes a good 2-3 seconds to spin up a UI on my i7.

Very simple, there's a couple of orders of magnitude greater number of developers and designers who have skill with web technologies than native UI. Similarly there's a couple of orders of magnitude more options of UI frameworks and design patterns. Add to the fact that Blink, Webkit, V8 and Chakra have been constantly pushing the bounds on speed bringing a web technology based front end within touching distance in t…

Very simple, there's a couple of orders of magnitude greater number of developers and designers who have skill with web technologies than native UI.

There is a very succinct rebuttal to that, and a good explanation for why apps based on "web technology" are they way they are: "quality is not quantity."

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

#643

Post by boterock » Fri, Mar 24, 2017, 3:50 AM UTC

charrondev wrote: post #567

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…

I don't much about graphic stacks, but in my experience the best, as least from the perspective of someone using multiple HiDPI displays macOS is far and away the best. Many windows applications don't scale properly or if they do they require special settings to do so. If you have monitors with different levels of scaling your going to have a terrible time on windows.

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.

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

#644

Post by Neeek » Fri, Mar 24, 2017, 4:06 AM UTC

boterock wrote: post #643

charrondev wrote: post #567

Earlier quoted context omitted.

I don't much about graphic stacks, but in my experience the best, as least from the perspective of someone using multiple HiDPI displays macOS is far and away the best. Many windows applications don't scale properly or if they do they require special settings to do so. If you have monitors with different levels of scaling your going to have a terrible time on windows.

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.

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 the 4k is your primary or secondary) and then scaled up or down to fit the monitor.

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

#645

Post by c-smile » Fri, Mar 24, 2017, 4:07 AM UTC

jblow wrote: post #521

c-smile wrote: post #447

Earlier quoted context omitted.

I am not sure I understand why do you need clipping at all to render rectangular caret bar (note: cursor is a different entity in UI professional jargon). What exactly you want to be clipped out?

I am assuming that your caret bar may be overlapping text in some way, or that there is a background bitmap that you might be alpha-blending against, etc. Basically I don't want to make an assumption that might break if the UI gets nicer. The case of a strictly opaque strictly rectangular non-antialiased non-smoothly-moving bar does not seem very interesting or nice-looking.

Are you speaking about some particular implementation of this all just from your imagination?

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

#646

Post by Hydraulix989 » Fri, Mar 24, 2017, 4:10 AM UTC

zbuf wrote: post #534

bitwize wrote: post #469

An 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…

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…

To be fair, X11 can't handle multiple displays with mixed DPI.

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

#647

Post by nitrogen » Fri, Mar 24, 2017, 4:17 AM UTC

Hydraulix989 wrote: post #646

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…

To be fair, X11 can't handle multiple displays with mixed DPI.

You sort of can with xrandr scaling.

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

#648

Post by aidenn0 » Fri, Mar 24, 2017, 4:28 AM UTC

audidude wrote: post #578

bitwize wrote: post #569

Earlier quoted context omitted.

It's the GNOME style of development: as soon as a bug appears which takes effort to fix, mark it EWONTFIX, declare it to be a symptom of the inherent brokenness of the current stack, then burn the whole thing to the ground and start over. Don't even let that which was burned fertilize new growth; it is tainted and must be purged entirely.

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 of the whole point);this is compounded by the fact that at the beginning it will be feature-poor compared to the older system.

"Why did you replace X with Y? With X, I could configure it to treat mouse-button-3 as mouse-button-2, but only when my USB mouse was not attached and I wasn't holding down any modifier keys."

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

#649

Post by pix64 » Fri, Mar 24, 2017, 4:33 AM UTC

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…

You could write a native text editor which can use JS plugins. Sublime Text uses python plugins and is nice and snappy.

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

#650

Post by ReverseCold » Fri, Mar 24, 2017, 4:44 AM UTC

Neeek wrote: post #644

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.

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