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

Post by dom0 » Thu, Mar 23, 2017, 6:51 PM UTC

mikejmoffitt wrote: post #419

joshuamorton wrote: post #146

Earlier quoted context omitted.

I think the fact that you call java not-compiled, but python interpreted shows your misunderstanding in this area. Both run exactly the same way, they are compiled into an intermediate bytecode which is run in a "VM". The normal Java VM has a JIT, the normal python VM does not, but pypy does and achieves performance on par with some of your compiled languages, at the cost of reduced c compatibility. I know C, Java, p…

For me, a big irritation with Python - intermediate bytecode or not - is that foolish small mistakes in formatting, or missing symbols, etc. will only make themselves apparent when the interpreter (or bytecode interpreter) actually tries to run or use them. In some configurations, it can be preprocessed and checked, but the most typical and default use cases for Python do not promote this.

Post by aerique » Thu, Mar 23, 2017, 6:55 PM UTC

krylon wrote: post #398

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…

Broken Sword let you play Breakout during the installation; it was such fun (I had not played Breakout in a long time at the point) I was almost sad when the installation was finished. ;-) I have often wondered since why this was not a more popular way to deal with long running installers.

Post by pcwalton » Thu, Mar 23, 2017, 6:55 PM UTC

revelation wrote: post #396

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…

WPF is perfectly fine for high DPI apps and still beats all this web stuff by orders of magnitude. CSS people still think a grid is a choice of "small" "medium" and "large" columns/rows. Haha.

Post by c-smile » Thu, Mar 23, 2017, 6:59 PM UTC

jblow wrote: post #405

c-smile wrote: post #388

Earlier quoted context omitted.

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

Post by eltoozero » Thu, Mar 23, 2017, 7:01 PM UTC

Zenst wrote: post #361

artursapek wrote: post #25

I'm reminded of this classic: https://github.com/npm/npm/issues/11283 NPM had a progress bar that was so fancy that it slowed down installation time (basically its only job) by ~50%. Hilarious. My mantra here is, if you find yourself thinking about implementing a fancy loading spinner/progress bar, it would be more productive to just spend that time making it unnecessary - speed up your shit! Obviously that doesn't a…

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…