[deleted]
VS Code uses 13% CPU when idle due to blinking cursor rendering
401–410 of 801 posts
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#402I had something like this happen with QNX, back in 2004 when we were using it for the DARPA Grand Challenge. We had an industrial x86 computer system that was running headless, with no display. But the device had a minimal VGA controller on the motherboard. So QNX brought up a screen saver on the slow VGA controller, where reading from display memory was very slow. The screen saver was reading from display memory to move the screen saver box around. This used up about 15% of the CPU.
The QNX people were really embarrassed about that and fixed the screen saver. We just reconfigured to turn off the display entirely.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#403Earlier quoted context omitted.
That's totally unfair. You should compare it to startup time of Word from, I don't know, 10 - 20 years ago. Around the same time (if not less), and Google Docs still can't match the features of old Words. The point being, for the past decade or two, we've been burning all hardware performance improvements on things that are neither visible to user, nor enable them to do more with their computer. Surely, there must be…
Why should he compare it to Word? Was it a cloud-based product that synced all files between multiple machines of radically different form-factors from PCs to phones? No? Google Docs uses the Internet, so did anything on an old modem. Word didn't (especially 20 years ago).
So word processors have to be slow to use the network?
I'm not sure your arguement makes any sense.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#404Earlier quoted context omitted.
That's totally unfair. You should compare it to startup time of Word from, I don't know, 10 - 20 years ago. Around the same time (if not less), and Google Docs still can't match the features of old Words. The point being, for the past decade or two, we've been burning all hardware performance improvements on things that are neither visible to user, nor enable them to do more with their computer. Surely, there must be…
On a per-application basis, you are probably correct. But if the additionally abstraction layers allow there to be greater diversity of applications and more tools for more niche cases because development is easier and/or faster, then that is directly immediately beneficial to the end user. Not to mention faster design iteration, implementation of new features etc.
> On a per-application basis, you are probably correct. But if the additionally abstraction layers allow ...
Windows 7 boots in approx. 5 seconds to the desktop (if no password is set), and stuff like Word or Visio starts instantaneously. Web applications on the very same computer are a whole different story.
Let's just acknowledge that SaaS is not and never was about any kind of benefits for the user or customer, but just about either centralising resources and services back to the vendor's control and/or increasing money extraction.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#405Earlier quoted context omitted.
"With the GPU the only viable option for rendering blinking caret is to redraw the whole window." Sorry, that is plainly false. There is nothing preventing you from treating an offscreen buffer just like any other buffer of non-dirty pixels. Treating the back buffer that way is slightly less conventional but is still just fine.
> There is nothing preventing you from treating an offscreen buffer just like any other buffer of non-dirty pixels. You need: 1. ability to invert pixels by CSS/JS. No such feature in principle. For many reasons. 2. Even if you will be able to invert those pixels in offscreen bitmap you need to send that window's offscreen bitmap to CPU on each caret blink. You can use tiles - so do partial CPU->GPU data transfer but…
None of the 3 things you said are true. I recommend you get some experience in rendering before you mislead people too much with these kinds of comments.
In reality the problem is trivial, you set up a scissor rect (or explicitly mask the pixels in your shader) and then render only stuff overlapping that square. You don't need to invert the pixels for it to be fast; you can render an arbitrarily nice cursor effect.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#406This is where Bert Bos (Created jokingly the notorious, unofficial, abused blink tag https://www.w3.org/Style/HTML40-plus-blink.dtd) should have a little "told you someone will need it someday" moment ;)
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#407Earlier 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.
> instead of a native widget that writes directly to the screen. "Writing directly to the screen" (by which I assume you mean writing pixels one by one to the framebuffer) is a bad idea for modern graphics hardware. It was fine on the 486, but nowadays you need the ability to do global optimizations for good 2D (or 3D) graphics performance. Ironically, the Web stack is much better positioned to do this than, say, Win…
It seems reasonable this might be true, but it's not. In video games we went down the road of retained-mode graphics APIs (declarative-type things, so that they can do the kinds of 'global optimization' you mention) but we abandoned them because they are terrible. Video games all render using immediate-mode APIs and this has been true for a very long time now and nobody is interested in going back to the awful retained-mode experiment.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#408Earlier 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.
Qt isn't native. They're drawing their own widgets that look close to native - that's why you can theme Qt apps.
Factually incorrect, since Qt uses native widgets when possible. Applying Qt stylesheets usually disables use of the operating system's styling engine, i.e. only then Qt starts drawing the widgets by itself. Widgets that are not part of the native widget assortment are drawn by Qt.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#409Thank you to the author of this github issue! I hope it gets sorted soon! I use VSCode a lot when disconnected from my power outlet.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#410Earlier 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.
[citation needed] - web application development is incredibly complex and can't be compared to just "web development" (e.g. writing a HTML document or template and styling it).