Skia VS Open-Source Vulkan C++ API

I use SkVx from Skia. It uses compilers' vector extensions and few platform-specific intrinsics. If no vector extension available (e.g. msvc), a scalar implementation is provided in the hope that compiler can vectorize it.

Regarding compiling to JS, you can compile dart to JS however when running Flutter on mobile platforms such as iOS or Android, you're not compiling to JS but instead you're using Dart to draw widgets on the screen via Flutter engine which uses a cross-platform graphics engine under the hood called Skia. If you're running on web on the other hand, your dart code would compile to vector graphics rendered within a canvas element in pure HTML.

It built on a render framework named skia, JetBrains create a kotlin mapping which named skiko for it.

Flutter applications are written in the Dart programming language, and can connect to platform languages such as Java, Kotlin, Swift, and Objective-C. Also, thanks to ffi support, it is possible to interact with the C code directly . Flutter itself is built with C, C++, Dart, and Skia (a 2D rendering engine).

Fleet does not use Compose, but it does use Skiko[1], which also provides binding for Skia[2] (the native graphics library also used by Chrome & Flutter).

The main difference between the libraries is that Skija provides Java/JVM bindings for Skia, whereas Skiko provides Kotlin bindings for Kotlin/JVM, Kotlin/JS, and Kotlin/Native targets. Of course Skiko's Kotlin/JVM bindings can be used with other JVM languages, not just with Kotlin.

[1] https://github.com/JetBrains/skiko

[2] https://skia.org/

RN Skia: https://github.com/Shopify/react-native-skia Skia itself: https://skia.org/

Yeahp, it renders the controls itself using skiasharp, which I believe uses skia

If you want CPU rendering perhaps tiny-skia meets your needs? Also proper Skia is generally the Cairo alternative, though I dunno that its any easier to use or compile than Cairo is. Alternatively you could try Raqote or Piet.

First step: Read the documentation. I see at the bottom of the github page that there's a link, so I go there: https://skia.org/

I was looking into the skia source code since I was curious on how it handled the renderering but I really don't know where to begin looking. There doesn't seem to be an entry file that handles the initialization and there are dozens of folders with hundreds of functions.

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.

Having this on the side and reading the actual implementation is in my opinion the best way to learn about using Vulkan compute and how the different parts of Vulkan are related. On the other hand you need to be at least little bit familiar with concepts of Vulkan (and vulkan.hpp) to understand it and know how would things change if you would change some options.

vulkan_structs.hpp - part of the Vulkan-Hpp library (Vulkan bindings for C++) comes in at 97967 lines of code.

https://github.com/KhronosGroup/Vulkan-Hpp/issues/926#issuecomment-810979142

Really?

The github doc says that there's an overhead to the Unique types since they must store allocation callbacks. Is that true for the RAII types too? which approach is better? What do I use?

There is nothing that requires doing any sort of RAII types. Personally, having each object be able to delete itself by keeping track of what created it so it can call a Vulkan destroy method doesn't really gain me anything. When I am dealing with an explicit API like this, I am really ok with being explicit about when I am done with a resource and it can be freed. These wrappers can also get you into trouble like this. On the off chance that I do somehow not free a resource when I am done with it, that is likely a hint at a bigger issue with my code that these sort of utilities will clean up and hide from the resource tracker in the validation layers.