Krita 4.1.3 Released
krita.org
krita.org
I commend the Krita team for not merely copying Photoshop/GIMP, but actually writing a program an idiot like me can pick up and actually be productive with.
I do have Krita both at work on Windows and at home on Linux, but I rarely have to pull it out unless I need a tool specific to that application.
>I commend the Krita team for not merely copying Photoshop/GIMP
Krita (as well as MyPaint) is mainly a painting software whereas Photoshop/GIMP are mainly photo editors. You can do similar things in both, but they target different niches.
Do not be fooled by its name. That merely tells you where it began; it does not tell you what it is useful for after nearly thirty years of adding on one feature after another.
I appreciated the comment as a light humoured jab at the insane amount of memory slack needs just to send some text to each other (over simplification).
I read it as a comment on Slack's performance, not as an attack on Electron.
I have ~2ms input latency using vim on xterm. I doubt VSCode can ever achieve this kind of performance, simply due to the poor architectural decision of using electron and JavaScript.
this does not really strike me as odd for emacs and vim - pretty sure that if you load them in a computer with a 640 by 480 screen in a 32-bit OS on IceWM it will be comparable to the olden days. On todays's 4k screens, just opening a window that takes half of your screen will alone cost a good dozen megabytes of RAM - and if your UI widgets do caching (they should, text rendering is expensive), then each of your widgets may allocate a pixmap too. When screens were 72 DPI and a button was 30 by 10 pixels it was fine... but nowadays you have to multiply all the values by at least 4.
And the switch to 64bit has instantaneously doubled the size of all the data structures working with pointers - which is generally a lot in GUI apps since most are trees of widgets. In some of the apps I've been working on, the RAM hit of 64bit has been more than 30%, and sadly the world does not seem to accept the x32 ABI.
And voilà, you can have your 32-bit pointers. You can even go down to 16-bits for small enough arenas.
(No, I'm not actually serious. Though we could imagine something similar on some new language.)
We can also have them with zero hacking since there is an existing ABI for 32 bits pointers in 64 bit mode: https://wikipedia.org/wiki/X32_ABI ; you get all the benefits of x86_64 mode (more registers, default support of SSE2 etc) for the memory usage level of x86 (and 4gb of accessible ram instead of x86 OSes's 2.something addressable gigabytes). I'm pretty sure that only specialized apps actually require >4gb of ram - most common utilities (e.g. shell, text editor, etc...) should really be compiled in x32 mode.
That's somewhat specialized, but not as much as you might think.
Why would you compare that with Slack?
We should all just stop comparing native apps to electron based apps, those things are soooo different. Electron/Chrome/Firefox/$browser are doing a ton of stuff behind the scenes, they are basically little virtual machines running the web platform. Comparing that to native is meaningless. You can of course prefer native apps, no one is arguing that, and yes you're correct that native apps will often use less resources, but it is the same as saying that a jumbo jet is much faster than a kickscooter, it might be true but what kind of comparison is that?! people are not building stuff with electron because they want to use less resources, the reasoning behind it is usually something else that those teams think is a valid trade-off
The general arguments are to do with building modern, aesthetic, easy-to-use cross-platform apps with less dev resources. Slack as a company are not dev-resource-constrained, so this makes Krita an exemplary counter-example to anyone who ever defended Electron for these reasons.
I use it at work and church and I have yet to find anyone who likes it (including myself).
They simply didn't know any better, and were enamored with the new level of internal communication vs. previous jobs.
Man it was such a time sink. Between the open office floorplan and slack this was the least productive environment I'd ever seen for an engineering company, and it's largely caused me to walk away from the industry.
By the same token, Slack fulfills a need and does so adequately; its features are enough to do interoffice communication without having to fall back on email or texting. I'm sure there are better tools out there, and Slack is definitely slower on our Core i3 based workstations compared to our beefier machines, but we don't "like" or "dislike" it.