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

481–490 of 801 posts

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

#481

Post by Mister_Snuggles »

coldtea wrote: post #475
Mister_Snuggles wrote: post #451

Earlier quoted context omitted.

On Win32[0], the blinking caret can be shown anywhere inside a window, not just on a text field. The sample program builds a basic text editor without cheating and using a textbox control. I'm sure other operating systems have this kind of facility - after all, how does the built in text edit control draw its caret? [0] https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...

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

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

#482

Post by jinglebells »

billconan wrote: post #159
Touche wrote: post #41

Earlier quoted context omitted.

I think I don't understand the issue well enough. This looks like a standard blinking cursor to me. Users expect a blinking cursor in an editable text field. I'm not sure why this implementation is slow or why they needed to implement it themselves and not let the OS handle the blinking cursor. I'm guessing there must be some reason.

this is exactly the same problem I met yesterday. I made a webpage based on a bootstrap template On this webpage, I have 2 realtime components. one is a chart, based on dygraphs the other component is a bootstrap progressbar. the bootstrap progressbar is made by html divs: https://www.w3schools.com/Bootstrap/bootstrap_progressbars.a... Both components are updated in realtime by a websocket. I noticed that the chart b…

Can you buffer the incoming websockets data and only update at a small percentage of the inputs or maybe based on time?

Lodash has a debounce function which is useful to throttle UI features hooked to incoming data. https://css-tricks.com/debouncing-throttling-explained-examp...

You never really want the UI repaint to be dictated by data, it's better to use timers.

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

#483

Post by sqeaky »

efdee wrote: post #304
thomastjeffery wrote: post #243

Earlier quoted context omitted.

> it's the best we have (if you're looking for a cross platform solution, anyway) No it's not. If you want a fast full-featured cross-platform GUI toolkit, there are many: GTK+ and Qt are especially great, and have bindings for several languages.

I can't speak for Qt, but GTK+ is not that great outside of the Linux bubble. IMHO, of course.

They aren't that great in the Linux bubble.

I say that from the developer and the user perspective.

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

#484

Post by coldtea »

pcwalton wrote: post #300
coldtea wrote: post #162

Earlier quoted context omitted.

> You both do realize that similar arguments could have been made back in the day when moving from, say, command-line DOS applications to Windows API applications - right? No, we don't. With Windows API there's no sandbox and extra embedded language overhead (it's still native code like in DOS, and even optimized better, able to use more available memory than DOS would allow, etc.). Oh, and you also got the benefit o…

> Not to mention that the Windows API UI toolkit, while bad, is sane compared to the web stack. Completely disagree. Charles Petzold's HELLO.C is hundreds of lines of code. Hello World on the Web is, well, "Hello world!". "Sane" environments don't force you to make up a distinction between "long pointers" and "pointers" if you want to conform to the house style in order to match 16-bit x86 real mode. Or route all eve…

>Completely disagree. Charles Petzold's HELLO.C is hundreds of lines of code. Hello World on the Web is, well, "Hello world!".

It's actually 87 lines of code, with a disclaimer comment, ample empty lines, a callback to play a wav when clicked, and an error message for when it's not run on NT. So, like 30-50 lines of actual Hello World necessary code. And that includes the starting up boilerplate.

That's about as relevant as complaining about the large binary size of a hello world program in a language creating static binaries. It might be larger than expected, but it usually includes a whole runtime. So once you add actual code, the binary's size doesn't scale linearly with the code size.

For comparison, a modern CSS "reseting" file, which just removes empty values is usually larger than the hello.c example.

This is the problem with trivial/contrived examples. They don't show you how the thing you're discussing scales in actual use.

In this case, the hello world in HTML is not representative of what you need to do to create a medium/large SPA in HTML.

And the old Windows api you could always wrap in higher order stuff, or even use as a basic layer to create your own UI library (still native).

The web stack, because of how it is done, you can't.

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

#485

Post by avian »

paulmd wrote: post #412
dheera wrote: post #382

Earlier quoted context omitted.

> Going to windowing GUIs from character-mode DOS was a massive usability improvement. No more exotic ctl-alt-function key combos cough Blender ...

Unfortunately - the OSS world has a shortage of good UX people, and the engineers tend to be the ones steering the ship. I would point to Eclipse as another classic example of "obviously designed by an engineer". There's tons of functionality under the hood and it's a fantastic jumping-off point for further customization... but its layout is intensely non-intuitive in so many ways compared to a purpose-built IDE. Eve…

I fear the day "good UX people" come to GIMP and Blender.

It used to be that OSS was developed by people that actually used it. Maybe it wasn't pretty, it had a steep learning curve, but it got things done and was efficient once you learned how. Often you got fresh perspectives on how an interface could be done, since people got fed up with existing solutions.

Nowadays you get UX experts preaching how an interface is supposed to look like, which mostly means copying Apple or Google. You get tons shiny whitespace. Burger menus, because that's what "everybody is used to".

GIMP with "good UX people" would turn into a bad copy of Photoshop.

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

#486

Post by caoxuwen »

kchoudhu wrote: post #473
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…

If you could n-gate every article as it's posted, that would be awesome.

bummer n-gate didn't comment on its own hn post

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

#487

Post by bitmapbrother »

brilliantcode wrote: post #18
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…

well if you've ever built a cross platform native desktop application, you will appreciate Electron. Java Swing. Never again. edit: Do people downvoting even know what it's like building cross platform desktop applications using Java Swing? It's fucking awful, and that's a fact. Even the end result UI design look & feel is butt ugly. Sure you can spice things up with JavaFX but why? Do you not realize how masochistic…

Is the IntelliJ UI "butt ugly"? No, but you'll probably say it is as to not contradict yourself. Blame the craftsmen not the tool.

>Even the end result UI design look & feel is butt ugly

You know what else is butt ugly? Programmer art and UI.

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

#488

Post by sqeaky »

PopsiclePete wrote: post #467
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.

I've done some raw C Win32 GUI programming and I've done some modern electron stuff as well. I know which I'd rather offer as my toolkit of choice for a project on which I wanted lots of people to contribute code to!

Please don't use win32 as an example for all native UI coding, its garbage. Consider Qt or anything else, even X11 looks good compared to win32.

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

#489

Post by merrvk »

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 would recommend Fastmail. Moved over for similar reasons and never looked back

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

#490

Post by rayiner »

monkpit wrote: post #350
rayiner wrote: post #130

Earlier quoted context omitted.

The web is in just a shameful state. Even with 300 mbps fiber internet most websites are not snappy. As in, pages are so slow to render that I'll start reading, but then lose my place when the page reflows as it continues to load. Or click on the wrong thing because the page reflowed while I was trying to click on something. As far as I can tell I'm actually CPU-limited, because I noticed no real difference from when…

So you just assume that changing between 50 meg and 300 meg service actually should give you a 6x speed up during browsing? I think that's a very flawed assumption to make. Just because your connection is capable of a certain advertised speed doesn't mean you're getting that speed from any given server as you browse the Internet.

No, I'm assuming that because it didn't give me a noticeable speedup that bandwidth isn't the bottleneck. Also, the bottleneck isn't my connection out to the internet because I can get more than the advertised speed any time of day to speedtest.net servers. I suppose the bottleneck could be on the other end, but aren't these sites all hosted on major platforms these days? Like AWS/Google/etc.?
Post reply on HN