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

661–670 of 801 posts

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

#661

Post by audidude »

fulafel wrote: post #658
audidude wrote: post #617

Earlier quoted context omitted.

That's precisely why I stated 20 years. Those programs were written before that and largely haven't changed since. If you wan't anti-aliasing in any of those above (gitk/emacs come to mind) you'll be doing client side rendering of fonts and copying pixels.

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

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

#663

Post by fulafel »

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.

If you want to optimize for choppy networks that have too much packet loss for interactive TCP applications , then the current X11 is not a good fit. But that would be a whole different niche.

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

#664

Post by bitwize »

fulafel wrote: post #658
audidude wrote: post #617

Earlier quoted context omitted.

That's precisely why I stated 20 years. Those programs were written before that and largely haven't changed since. If you wan't anti-aliasing in any of those above (gitk/emacs come to mind) you'll be doing client side rendering of fonts and copying pixels.

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

Actually, RDP is GDI over the wire, which is not too dissimilar from X.

RDP has efficiency gains because clients send pixmaps over the wire to be stored on the server, and then send draw calls to display those pixmaps in certain places, composing a display. You can do this with X11 too, but the GTK developers don't want to because using the protocol is hard ;_;

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

#665

Post by bananaboy »

jdonaldson wrote: post #232
cr0sh wrote: post #112

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? Ultimately, computing has always been one of abstraction from the lower "layers". Taken far enough, one could spuriously argue that if you aren't soldering together the flip-flops that make up your logic and memory, you just aren't being efficient...

Except we're using divs , markup elements originally intended for research documentation, and using them to emulate modern UI techniques. I don't mind abstractions, but we should at least be using something built to task.

The most egregious example of abuse of technology for me is the browser version of Wolf3d, where they used divs to essentially replicate the vertical column drawing of a raycasting engine: http://3d.wolfenstein.com/

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

#666

Post by Sharlin »

biggiesmalls wrote: post #583
paulirish wrote: post #244

Earlier quoted context omitted.

Powerful* text editors built on the web stack cannot rely on the OS text caret and have to provide their own. In this case, VSCode is probably using the most reasonable approach to blinking a cursor: a `step` timing-function with a CSS keyframe animation. This tells the browser to only change the opacity every 500ms. Meanwhile, Chrome hasn't yet optimised this completely yet, hence http://crbug.com/361587 . So curren…

>> text editors built on the web stack cannot rely on the OS text caret Can you explain in simple terms why this is the case? Why on earth not?

Because you can't just ask the OS to "please paint text caret here thankyou", and browsers do not expose a powerful enough native text editing control. So you end up reimplementing one in JS/HTML/CSS, including the caret.

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

#667

Post by [deleted] »

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.

[deleted]

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

#668

Post by Sharlin »

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.

> You can specify pixel values in CSS if you like.

And many (most?) do... leading to the reinterpretation of what "pixel" means in the CSS spec. Yes, CSS pixel does not mean a physical pixel on the screen.

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

#669

Post by pjmlp »

smitherfield wrote: post #657
abiox wrote: post #619

Earlier quoted context omitted.

>Socrates: OK! So could you show me a real application then? Like, it says "Hello, world!" in a window, with a menu and buttons and stuff? And it will be the same on both Windows and Linux? >Developer: No, that's not possible. swing? awt? javafx?

I exaggerate somewhat, but all three are low-quality and further development appears to be abandoned.

They are good enough in the hands of those that care to learn how to use their APIs, and way better the web will ever be.

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

#670

Post by rl3 »

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.

>... 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 without DPI scaling. I'd probably even prefer 30" myself.

Post reply on HN