201–210 of 801 posts
Earlier quoted context omitted.
This might mark the first time in history that Emacs was trotted out as an example of a performant editor. I say this as an Emacs user.
Emacs takes 8-15 seconds to open on my new i7. That matters when I just want to do quick edits. Vscode takes 3.
Earlier quoted context omitted.
...a whole 2-3 seconds! Sometimes I think that comments like these arise out of not having experienced text-only rendering at 300 baud... I know that's a generalization, and most likely unfair - but damn, today's phones, to this old man, are pocket super-computers (for that matter from my vantage point, an Arduino is a wonder, and a RasPi is utterly amazing)!
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…
Google Docs uses the Internet, so did anything on an old modem. Word didn't (especially 20 years ago).
>A workaround for folks who are similarly obsessed about battery life That's odd wording. Obsessed because I don't want to waste energy, which leads directly to pollution? Or don't want a short battery life on my laptop? Power savings shouldn't be seen as irrelevant geekery. 13% is half the capacity of a single core in a four core processor. My 5 year old 2500k peaks at 120 watts. So 15 watts to render a cursor? Micr…
It seems that these days anything that a developer doesn't care about is seen as "irrelevant geekery".
It 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…
Earlier quoted context omitted.
Pray tell, sir, have you heard of the Qt library? There is a whole world outside Javascript :)
So you think hacking QT libraries like this (and not from the outside, I mean internally) and using C++ would make a good community editor? http://doc.qt.io/qt-5/qtwidgets-richtext-syntaxhighlighter-e... When using QT for a highly modular editor be prepared to code QT components from the lowest level. It's not like you take a QT widget and modify it on a simple way. Trust me. If you think it is easy to code editors l…
The real problem is this new generation of "developers" that only know Javascript. When all you have is a hammer...
Earlier quoted context omitted.
Emacs is a little harder to write plugins for, but it runs natively and the only impediment is that more people know JS than they do elisp.
Lots of emacs functionality runs via its lisp VM. I'd hardly call that 'native'. I mean, Emacs had jokes about being bloated decades before Javascript (and Java, another contender for these jokes) even existed. :)
Quote from the article;
> The blinking cursor causes the processor and GPU to be woken up frequently. On one of my test systems, this causes somewhere in the region of 2 Watts of extra power consumption.
This isn't about electron vs "native" apps. It's just that a smooth cursor animation rendered at 60Hz costs power; and if you look at the github issue, one config setting and that's gone, and so is the power usage when idle.
Earlier quoted context omitted.
> easy to get started Yes. > cross platform support Yes. > Because you can write plugins in JS? Yes. --- As much as I prefer native programs as a user, it's impossible to ignore the benefits of cross-platform development and plebeian hackability/debuggability.
>> cross platform support > Yes. WOW FINALLY SOMETHING that will run on my LINUX and FreeBSD! ohh.. a lot of plugins don't support linux and it doesn't build on BSD?
Earlier 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.
> I'm not sure why this implementation is slow I'm guessing the culprit for that is in this part of the bug report: > Zooming into a single frame, we see that while we render only 2 fps, the main thread is performing some work at 60 fps (every 16 ms) As for > why they needed to implement it themselves and not let the OS handle the blinking cursor They're not editing inside a text editor field anymore, they need to bl…
Earlier 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.
> I'm not sure why this implementation is slow I'm guessing the culprit for that is in this part of the bug report: > Zooming into a single frame, we see that while we render only 2 fps, the main thread is performing some work at 60 fps (every 16 ms) As for > why they needed to implement it themselves and not let the OS handle the blinking cursor They're not editing inside a text editor field anymore, they need to bl…