Open-Source Vulkan C++ API VS Skia

It might be useful to maybe look at the Vulkan.hpp examples since you can do the same in about 200 lines of code. https://github.com/KhronosGroup/Vulkan-Hpp/blob/main/samples/15_DrawCube/15_DrawCube.cpp

Even auto-generated c++ wrappers like vulkan-hpp require lots of manual maintenance.

Ultimately I went with vulkan.hpp RAII bindings, even though that way also has some learning curve and I couldn't find any documentation other than the RAII programming guide. It's great for getting started, but could use a complementary auto-generated API doc. There are also decent programming samples, which really suck for getting started, but otherwise do a good job of presenting concepts they focus on. Putting the available resources together I was able to get a project going in two weekends.

Or the vulkan.hpp RAII samples would be a good place?

For a real-life example: consider the vk::raii namespace of Vulkan-Hpp, where the developers have posted examples. The vk::raii::su namespace has a bunch of free functions that one might think are associated with a Vulkan instance/object (in fact, the Vulkan Tutorial does implement them as member functions), but they are much nicer when used as pure functions. It keeps the class/struct definition itself nice and clean.

VS 2022 has seen a massive increase in performance especially after its move to 64-bit. It lints even the largest headers (ahem, Vulkan-Hpp) in a matter of seconds whereas CLion just chokes and crashes.

So I am attempting to follow the Vulkan Tutorial, but I am trying to use decidedly more C++ than the tutorial suggests, by using the Vulkan-Hpp C++ bindings and the vk::raii classes, in particular.

Its literally a few kb: https://github.com/KhronosGroup/Vulkan-Hpp/tree/master/vulkan Why on earth are you downloading all the samples and what not? Just use the hpp files and be done with it. SMH

All the current major game engines are C++. C hasn't been widely used since the Quake 3 days.

While yes the Vulkan & OpenGL APIs are pure C, that's very, very little of what you actually code against. You very quickly abstract that or use a middleware like bgfx or whatever. In the case of Vulkan while the spec API is C, there's first-class C++ wrappers/bindings provided as well: https://github.com/KhronosGroup/Vulkan-Hpp

And other than Vulkan & OpenGL, you'll find that most other APIs/libraries in the space are C++, not C. Valve's libraries are C++. Dear ImGui is C++. Bullet & PhysX are C++. Microsoft's glTF SDK is C++. etc...

You can argue endlessly about how "true C++" those all are or if they're just "C with namespaces" but that's largely irrelevant - they aren't C and they need a C++ compiler.

Actually, that's not entirely accurate. The lottie-web library itself doesn't support rendering to WebGL. However, there is a package called canvaskit-wasm that wraps Skia (a graphics engine) with WebAssembly (wasm). This package includes a module called skottie which supports rendering animations into a WebGL surface. However, there is a drawback with this approach: using wasm requires loading a relatively large package, and it's uncertain whether all features are supported correctly, as the official compatibility table that tracks lottie support on different platforms does not include skottie.

Skia is pretty great if you can get it running.

There’s also Skia by Google. Used by Android and Google Chrome.

Not specially something that you cannot do without WASM but at $WORK we are using a WASM build of Skia [0] to render canvas from nodejs.

Why use WASM ? Because we wanted to stay close to our stack (ie. calling wasm from nodejs). Do it work ? Yes, memory consumption is quite heavy though (each WASM module have its own heap that can quickly grow).

However we are looking to directly use Skia now and avoid the overhead of WASM so i think its a nice solution in the beginning but you might want to ditch it later on.

[0]: https://github.com/google/skia/tree/main/modules/canvaskit