There are a few of those out there. Nanovg seems to be the one that fits your requirements most closely. If you're into Rust, lyon (plus something like gfx-rs) is another choice.
It's also worth noting that the HTML canvas implementations in most browsers is also not too bad for performance. Quartz is also really fast, but Apple made it really easy to accidentally use a slow rendering path (especially for bitmap operations)
So, I decided to teach myself a few years ago. I made notes as I went, and the process of learning a skill like this is really quite interesting.
The first piece of advice I’d give you is to go out and buy some books. Specifically, aim to buy things that you think you’ll still want to refer to no matter how far you take your skill, rather than books aimed at beginners: books designed as reference books and aimed at artists are ideal. First book I bought was ‘Color and Light’ by James Gurney. Also, buy the book Art & Fear if you don’t own it already.
At first, this is all about fear of failure. One of the main differences in the way children learn to adults is that children don’t have this fear. It’s taught and it can be unlearnt, but you’re probably going to have to confront it at some point. Sooner is better. Books and lessons aimed at beginners almost never help here. The usual beginner-type books instead try to teach lessons that you can succeed at, trying to avoid doing things that trigger that fear. To learn, you need to try to do things you can’t already do, not avoid them (this is also the key difference between practice and rehearsal. To learn something new, you need to make sure to practice and not rehearse).
What I think is that it's better to try to learn from sources that are beyond you than those that are already in your grasp. The problem is that at first, it’s very discouraging to try to do these kinds of things. So particularly at first, I’d recommend dealing with your feelings about painting much more than the actual skill itself. In particular, remember things that make you want to paint so you can find a reason to paint every day. When it comes to fear, curiosity is its antidote. If you try to achieve a specific effect in a particular painting, you can fail and that hurts; if instead you’re just curious about what would happen if you try something new, the results are just interesting. Occasionally they’ll be much better than you’re expecting, and those instances are addictive.
The overall process of learning these skills is interesting: at first it’s a bunch of small isolated skills, like the fine motor skills needed to make your brushes go where you intend. It’s quite frustrating because things don’t work together at first - so you might find that you're able to draw individual shapes quite well but they all look wrong when you try to put them together into a picture, or your shading will always look blobby and weird in an actual picture even though it looks OK when you focus on just that. Here’s the interesting thing: the isolated skills start to link up and it seems to be a sudden thing.
For example, I once set aside a day to just focus on learning how to build up shadows as nothing had ever worked well in the past and found to my surprise that there was nothing left to learn - things I’d already learnt just linked together and everything I tried came out exactly as I'd intended (which was a great feeling as I'd been learning for 2 years at that point and 'draws weird shadows' was starting to etch it's way into my identity). I had a similar experience with learning to draw in perspective.
There’s another stage too: after a while of things linking up it develops into a kind of language - which makes me wonder if that’s what language actually is: just a way to organize and regulate different interconnected parts of the mind: it definitely explains a lot about why the experience of drawing and painting comes so naturally to some people yet is so hard to properly explain to others.
Hi, you might be interested in a crate I wrote called desync: https://docs.rs/desync/0.3.0/desync/ - it provides a very simple yet expressive API for performing asynchronous operations and has full support for the futures crate. It can be learned really quickly.
Desync takes a slightly different approach to asynchronous programming: instead of being based around the idea of scheduling operations on threads, and then synchronising data across those threads, it's based on the idea of scheduling operations on data.
There's only two basic operations: 'desync' runs an operation on some data in the background, and 'sync' runs one synchronously.
All operations are run in order and 'sync' returns a value so it's a way to retrieve data from an asynchronous operation. It's sort of like setting up some threads with some data protected by a mutex and sending results between them using mpsc channels, except without the need to build any of the scaffolding. ('sync' also makes borrowing data from one task to use in another effortless)
For running as a local app, what I really want is to be able to run the server as a UNIX-domain socket. (Well, I can do that fairly easily but what I really want is for browsers to be able to connect to one of these).
For a single-user app the main issue is that it could be running on a multi-user system so there's the possibility of contention for ports and so on, as well as the need to verify that the right person is connecting - while it's possible to just bind the server to the loopback address anybody on the same system can access it there so it's not necessarily secure enough. For localhost verification, accessing/setting some information from a file URL might work.
With the loopback address, encryption doesn't seem to matter too much: anybody capable of intercepting traffic between a piece of software and the browser will also be in a position to just directly read what you're typing. Possibly by looking over your shoulder.
However, one of the reasons I want a HTTP UI is to make it possible to use something like an iPad as an input device and there are definitely issues there when the service is something that's randomly stood up and torn down and usually running on a local network rather than the internet: in particular TLS really expects a centralized service so it seems anything other than a self-signed certificate isn't going to work and that comes with a bunch of scary messages for the user.
The other issues of authentication all seem to be much the same as for any other web app, though it seems to me that it's possible to streamline it a bit as it'll be quite common for a user already authenticated on one device only to need to prove that they're the same user on another.
I wish you luck because the standards are a mess, but the terminal seems to have been ‘good enough’ for quite a long time (which is why all the standard originate in the 1980s). I think to make a new terminal stick, it’ll need to do something that is impossible with the current implementations rather than just try to sort out the mess.
One possibility is graphical output. It’s not easy to write a ‘simple’ application that produces graphics right now in the same way you can write one that outputs text to the terminal (also: ‘moving on’ from a simple design to a more polished one generally involves rewriting the graphical portion).
A more random pet peeve: when you run a command and it goes wrong, usually the most useful error message is the first one it displays, but the terminal will scroll to display the last errors which are usually less interesting. A ‘workbook’ style terminal (like you might see in a CAS) might ameliorate this problem? It also helps with a command outputting a giant pile of garbage because a parameter was wrong, as well as the issue where if you’re running something like a compilation job over and over to fix errors it’s hard to tell which messages were from the most recent vs the previous command.
I noticed with the languages I was working on, the problems could be resolved by being smarter with the lookahead: this parser allows for context-free lookahead matching to resolve (or detect and defer) ambiguities.
That makes it possible to do neat things like parse C snippets without full type information or deal with keywords that aren't always keywords (eg, await in C#).
https://flowbetween.app
Seemed like a good way to combine my interest in building software with my other interest in creating art.
I've been spinning off the various components needed to build it as separate rust crates: interesting ones are flo_curves, desync and flo_binding.