carbon footprint
Yeah. Somebody is putting coal on a fire so I can have a cursor blink on my screen. Makes you think :)
VS Code uses 13% CPU when idle due to blinking cursor rendering
261–270 of 801 posts
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#262Earlier quoted context omitted.
I don't get this criticism. HTML/CSS is the closest we have to a universally understood syntax for designing interfaces. Why invent a new standard? HTML is fine, CSS is fine. Most importantly, everyone understands it and can work immediately with it. Any issues with performance is due to the implementation of the platform that renders this HTML/CSS interface. It's much more likely Google Docs feels sluggish due to th…
Just because it's the best we have (if you're looking for a cross platform solution, anyway) doesn't mean that we've reached the peak and can just quit. We can do a hell of a lot better, and doing anything less is tragically underselling ourselves. There are no laws of physics preventing a better solution from existing. No, creating something better isn't easy, but neither have any of the other technological breakthr…
"Quitting" is not how I'd describe Atom and VS Code.
You might not like the envelope they are pushing, but they are cutting-edge explorations into web tech, coinciding with other cutting-edge developments like HTML/JS -> Native interfaces.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#263Earlier 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…
It's the typical web story. You can get to "good enough" with blazing speed, but the limitations of the web make it hard to achieve a high level of polish.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#264Earlier quoted context omitted.
Emacs takes 8-15 seconds to open on my new i7. That matters when I just want to do quick edits. Vscode takes 3.
For me Emacs opens up in about 2 seconds and it's ready to go and print text input in scratch buffer. I am on 2015 MacBook Pro 13" with i5.
For me, it takes <700ms, but that's because I leave it running all the time and call emacsclient from the command line.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#265Earlier 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…
There is an HTML 5 progress tag supported by all browsers:
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#266On one hand, I'm annoyed that javascript and browsers are being used for a text editor. On the other hand, I'm reminded of the arguments against emacs using 8 MEGS of memory and how terrible that is. I've learned to just relax and use what works. People have chosen to concentrate on extensibility at the expense of current day performance. The result has been good enough. There is probably something else to be said ab…
> On the other hand, I'm reminded of the arguments against emacs using 8 MEGS of memory and how terrible that is.
Yeah, but back then Moore's Law was running full steam and we were getting tremendous advances in processor and memory performance every year. Now that era has ended; what processor performance we have today is likely to remain more or less the same for the foreseeable future, barring a miracle from the chipmakers.
It's time to stop pissing away performance by using inefficient software stacks and web technologies are a big, juicy target for cleanup.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#267Earlier quoted context omitted.
Or you could use Lisp, and have the UI be S-Expressions. Everything can edit a list
Can you give me an example of a Lisp UI library like that?
Two come close but aren't quite there...
Seesaw [0] - A nice-ish way of using Swong in Clojure.
Iup [1] - One of the friendliest GUIs I've used, hands down. Just feels like Scheme.
However, I'd expect that QML and X-Expressions could go hand in hand to make something much closer, with a bit more flexibility.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#268I think the reason using the browser for desktop UI is because graphics and UI programming is terrible. The computer architecture and operating systems we use today are built on tech that was before graphics existed.
That's why it's trivial to build a terminal app, but god help you if you want to create a window with a button or draw a line. GLEW, GLUT, Qt, OpenGL, and the rest are just kludges to deal with the fact that we're still working with tech from the 70's. Even those kludges are so terrible that companies like Github and Microsoft have resorted to using the browser to make things like Atom and Visual Studio Code.
It can be fixed, but I'm not sure anyone has the fortitude to redesign hardware and operating systems.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#269Earlier quoted context omitted.
I tried it too... Wasn't satisfied with performances. I used to install Atom every 2,3 months, when VSCode got released I then tried installing it every few months in place of Atom. I still do, but I always uninstall after few hours of using it. It has many good ideas implemented well, but still not worth switching and sacrificing all of the performance for nice git and debugging interface.
VS Code is faster than Atom (by... a lot) tho? Especially with large files, but just in general. Speed is the main reason I can't stay using Atom for more than a few hours. It's awful. VS Code is snappier than Sublime Text ffs...
Wait, why? I use Atom on daily basis, don't have very strong machine, but I've never seen performance issues.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#270It 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…
We have a lot of native GUI text editors. Gedit, Geany, Kate, and Notepad++ are free options, and then you have Sublime Text as a proprietary one. They all support plugins and extensions, they are all super efficient in CPU usage, etc. The thing is they aren't new, and because they are all C/C++ codebases developers wanting to add new features to text editors don't want to touch C++98 / ANSI C code from two decades a…
CADT, all the way down...