Internally they are C++/Objective-C, but with a C API for easy consumption by any other programming language known to man. Yes, somebody would have to write the FFI definitions for Nim, but given the simplicity of my API, that's a day's work at most (or just add them incrementally as you need).
OpenWL is like GLFW, except instead of OpenGL it provides a native platform context (Direct2D, NSView, or Cairo context). And I don't know much about GLFW, but in the past I noticed that most GL apps ran a loop as fast as possible, and polled for input. Whereas OpenWL is, like the windowing systems it's based on, event-driven and only does anything when some kind of input/invalidation event comes through. So it is really not suitable for games; it's sole purpose is to provide a foundation for conventional GUIs. Speed-wise, it's usually slower - much slower - than NanoVG, but potentially much faster than Cairo. Let me explain: macOS uses Quartz2D natively, which (as far as I know) is still a pure CPU library. They experimented with GPU acceleration many years back but (again, as far as I know) that experiment was abandoned. However, what prompted me to make my own drawing library, was that Cairo was far too slow on the Mac - from what I could gather, this had something to do with Quartz performing color space transformation on every blit (of the Cairo buffers in memory). Perhaps that issue was eventually fixed, I'm not sure. But it was still an issue in late 2017 when I started all this. Windows uses Direct2D natively. This is GPU accelerated, and very very fast. It blows stock Cairo out of the water (unless perhaps you're using Cairo with a GL backend - but I did not mess with that and I have no idea if it's feature-complete). Basically I wanted to focus on whatever the platform-native options were, because those are most supported, and likely to look the nicest - especially where font rendering is concerned. Quoting my post on the D forums: > Now, an alternative to OpenWL/DL might be something GLFW+NanoVG. And I > certainly looked into those kinds of options before going this route. But > ultimately I decided against it, because I wanted to build on top of what > Apple/Microsoft/GNOME are actively working on. I figured, let the big > companies focus on making what they feel are the best drawing APIs for their > respective platforms, and I'll just ride on their coattails (and > optimizations) ... > > At this time, a purely OpenGL drawing library is still a little too DIY for > me. Now maybe if the Slug text rendering library were open source, and a > number of people were actively trying to integrate it with NanoVG, then I > could be persuaded... As for Linux, well, there's pretty much Cairo and that's that. Again, I haven't played with the GL backend, so I don't know what its performance would be. In theory it would just be a matter of compiling Cairo with that support, and maybe using a different context constructor, and then whatever performance gains there are, could be obtained for free. That's not a huge priority but I'm certainly open to investigating it / PRs that enable it. I do think that fluid interfaces are important, and I am going to look into the possibility of implementing (some) Core Animation functionality on Windows and Linux, because that's how Apple enables fluid animations and transitions on the desktop, given the CPU-bound nature of Quartz2D. (You draw into layers with the CPU, and then the GPU animates those layers).
