Earlier quoted context omitted.
This reminds me of one of my favorite old tech stories. A long while back (seems like this was the late 90s or early 2000s) I was working on a script that did some data processing on a remote machine. It had to loop through a bunch of text log data and generate some reports. Being as that I had no idea if the script was actually working until it completed awhile later, I decided to put in a neat little ASCII spinner…
Nice foot gun story. If you had a T1 at the time, you would never had noticed such a pitfall.
VS Code uses 13% CPU when idle due to blinking cursor rendering
501–510 of 801 posts
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#502Earlier quoted context omitted.
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 retain…
You build custom retained-mode APIs on top of the immediate mode APIs—they're called game engines. What happens if you try to present an immediate mode API for UIs is the status quo with APIs like Skia-GL. You frequently end up switching shaders and issuing a new draw call every time you draw a rectangle, and you draw strictly in back to front order so you completely lose your Z-buffer . Imagine if games worked like…
"What happens if you try to present an immediate mode API for UIs is the status quo with APIs like Skia-GL."
I don't know what Skia-GL is, but in games, the more experienced people tend to use immediate-mode for UIs. (This trend has a name, "IMGUI". I say 'more-experienced people' because less-experienced people will do it just by copying some API that already exists, and these tend to be retained-mode because that is how UIs are usually done). UIs are tremendously less painful when done as IMGUI, and they are also faster; at least, this is my experienced. [There is another case when people use retained-mode stuff, and that's when they are using some system where content people build a UI in Flash or something and they want to repro that in the game engine; thus the UI is fundamentally retained-mode in nature. I am not a super-big fan of this approach but it does happen.]
"and you draw strictly in back to front order so you completely lose your Z-buffer"
That sounds more like a limitation of the way the library is programmed than anything to do with retained or immediate mode. There may also be some confusion about causation here. (Keep in mind that Z buffers aren't useful in the regular way if translucency is happening, so if a UI system wants to support translucency in the general case, that alone is a reason why it might go painter's algorithm, regardless of whether it's retained or immediate).
"But that's the API that these '90s style UI libraries force you into."
90s-style UI libraries are stuff like Motif and Xlib and MFC ... all retained mode!
I don't agree that an IMGUI style forces you into any more shader switches than you already would have. It just requires you to be motivated to avoid shader switches. You could say that it mildly or moderately encourages you to have more shader switches, and I would not necessarily disagree. That said, UI rendering is usually such a light workload compared to general game rendering that we don't worry too much about its efficiency -- which is another reason why game people are so flabbergasted by the modern slowness of 2D applications, they are doing almost no work in principle.
Back to the retained versus IMGUI point ... If anything, there is great potential for the retained mode version to be slower, since it will usually be navigating a tree of cache-unfriendly heap-allocated nodes many times in order to draw stuff, whereas the IMGUI version is generating data as needed so it is much easier to avoid such CPU-bottlenecking operations.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#503Earlier 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…
Isn't this a false dichotomy? Why not create more modern, declarative native APIs and libraries, or use them where they already exist?
> we don't need the new stuff
> how about we throw both away to shut everyone up, would that make either side happy?
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#504Earlier 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…
Isn't this a false dichotomy? Why not create more modern, declarative native APIs and libraries, or use them where they already exist?
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#505Earlier quoted context omitted.
VS Code and Atom aren't really comparable for performance. VS Code is much, much smoother and closer to the experience of Sublime. > or example latest StackOverflow survey, showed that Notepad++, Vim and Sublime combined are used much much more than VScode and Atom combined By this metric Notepad++ and Visual Studio (not Code) are the best editors because they topped out of every category (except Vim for Sysadmin / D…
You should also sum all the procentages of Intellij based IDEs there, then VSCode is one place down
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#506Earlier quoted context omitted.
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.
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?
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#507Earlier quoted context omitted.
VS Code and Atom aren't really comparable for performance. VS Code is much, much smoother and closer to the experience of Sublime. > or example latest StackOverflow survey, showed that Notepad++, Vim and Sublime combined are used much much more than VScode and Atom combined By this metric Notepad++ and Visual Studio (not Code) are the best editors because they topped out of every category (except Vim for Sysadmin / D…
You should also sum all the procentages of Intellij based IDEs there, then VSCode is one place down
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#508Is this a MacOS only issue? Does it affect Atom?
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#509Earlier quoted context omitted.
You build custom retained-mode APIs on top of the immediate mode APIs—they're called game engines. What happens if you try to present an immediate mode API for UIs is the status quo with APIs like Skia-GL. You frequently end up switching shaders and issuing a new draw call every time you draw a rectangle, and you draw strictly in back to front order so you completely lose your Z-buffer . Imagine if games worked like…
Ehh, game engines are not really retained-mode in the way you mean. There isn't usually a cordoned-off piece of state that represents visuals only. Rather, much of that state is produced each frame from the mixture of state that serves all purposes (collision detection, game event logic, etc). "What happens if you try to present an immediate mode API for UIs is the status quo with APIs like Skia-GL." I don't know wha…
Here is a (somewhat old) video explaining some of the motivations behind structuring things as IMGUI: https://www.youtube.com/watch?v=Z1qyvQsjK5Y
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#510Earlier quoted context omitted.
> 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.
No need to have an official OS caret function (especially if you're not a native text field, and caret aside, the rest of your text editing will be different/broken in subtle ways compared to the OS).