NIH (Not Invented Here) syndrome reigns. It’s human nature. 
Hey!
I think the most useful recent development comes from the gfx-rs team ( https://github.com/gfx-rs/gfx ), which is a Vulkan-like graphics layer that redirects to a graphics interface of choice (Vulkan, DirectX, Metal, OpenGL). gfx-rs is slowly becoming the de-facto standard for low-level graphics programming in the rust world. There are also interfaces for NanoVG for rust - not sure if somebody has ported those over to make use of gfx-rs. Then there is also webgpu-rs which sits on top of gfx-rs and provides a native interface to the GPU abstractions that the webgpu standard established, which is less technical.
Personally, I see something that is backed by gfx-rs as the best bet, since the library has quite a momentum and development is done to a very high standard. I’ve not dug too deep into it, but for C++ only development, https://github.com/bkaradzic/bgfx supports multiple rendering backends and there is also a NanoVG port! Qt or something doesn’t resolve the issue here, since they did not abstract from the graphics layer at the lowest level of rendering. Last I’ve heard, GTK is moving a little bit closer to the rust world.
As an alternative to NanoVG for vectorized drawing, there is also Skia ( https://skia.org), which powers chrome, android & a bunch of others. It does have modern hardware abstractions (Vulkan, …). And then there is also Cairo (as far as I know without Vulkan support). Especially Skia is a huge dependency, though. On the other hand it is well tested and performing.
I don’t believe that OpenGL will be abandoned too soon by Apple. But I think Vulkan/Metal are the obvious way forward since they remove much of the functionality from potentially buggy driver implementations, whether this will count for old hardware, is another issue, I guess…
1 Like
Skia’s support for Metal is still a work in progress:
https://bugs.chromium.org/p/skia/issues/detail?id=8243
and it does not have a native DirectX backend; it uses Angle instead.
As mentioned, Skia is very large, but fast.
While Skia could be used as a replacement for NanoVG, 98% of the code in Skia would go unused.
The clients for Skia usually draw using an invalidation model, so only the parts of the screen that change are redrawn. Rack draws the entire scene every frame. This means that a good deal of Skia’s drawing architecture is not a good fit for Rack’s design.
Disclaimer: I worked on Skia for over ten years.
1 Like
That’s an odd usage of the term “drop-in replacement”. A NanoVG wrapper would need to be written so that for example, nvgRect(NVGcontext* ctx, float x, float y, float w, float h) adds the path to a stack and eventually calls SkCanvas::drawRect(const SkRect& rect, const SkPaint& paint);. Are you saying this exists already?
Skia’s is designed to make the implementation of Canvas and SVG as thin as possible. When I wrote ‘drop in replacement’ I was thinking that the shim between NanoVG’s interface and Skia’s would be minimal, and might leverage Chrome’s source. But I see your point, and have edited my original post.
1 Like
I have to thank you for that advice! I learned a lot working through these links. It is slightly off-topic but has anyone a suggestion for a simple lock-free single-reader-writer queue with an GPLv3 compatible license? I tried GitHub - cameron314/readerwriterqueue: A fast single-producer, single-consumer lock-free queue for C++, but it fails to build on MacOS (Windows and Linux is Ok) on my Azure Pipeline and I have absolutly no clue what to do about the error.
compiles cleanly and all tests pass for macos, but I’m doing in on a live machine.
1 Like
Thanks for testing! I will look into my build pipeline…
I’m also using moodycamel::ReaderWriterQueue and it’s compiling cleanly for me, again on a physical machine rather than Azure. But I will want to build it on Azure once this plugin is finished, so any advice you can pass on will be gratefully received!
(Just in case it’s relevant, I’m compiling with -std=c++14 for other reasons - I don’t know whether that’s relevant to ReaderWriterQueue.)
its own makefiles build with -std=c++11, so likely not the issue. I’ve never compiled with azure, but if someone posts compile issues, it’s probably something straightforward.
I get this error:
In file included from src/queue/readerwriterqueue.h:7:
src/queue/atomicops.h:246:55: error: no matching constructor for initialization of 'std::atomic<Block *>'
template<typename U> AE_NO_TSAN weak_atomic(U&& x) : value(std::forward<U>(x)) { }
^ ~~~~~~~~~~~~~~~~~~
src/queue/readerwriterqueue.h:680:54: note: in instantiation of function template specialization 'moodycamel::weak_atomic<moodycamel::ReaderWriterQueue<EpsMidiMessage *, 512>::Block *>::weak_atomic<int>' requested here
: front(0), localTail(0), tail(0), localFront(0), next(nullptr), data(_data), sizeMask(_size - 1), rawThis(_rawThis)
^
src/queue/readerwriterqueue.h:705:32: note: in instantiation of member function 'moodycamel::ReaderWriterQueue<EpsMidiMessage *, 512>::Block::Block' requested here
return new (newBlockAligned) Block(capacity, newBlockRaw, newBlockData);
^
src/queue/readerwriterqueue.h:112:18: note: in instantiation of member function 'moodycamel::ReaderWriterQueue<EpsMidiMessage *, 512>::make_block' requested here
auto block = make_block(largestBlockSize);
^
src/EpsMidi_InJack.cpp:10:2: note: in instantiation of member function 'moodycamel::ReaderWriterQueue<EpsMidiMessage *, 512>::ReaderWriterQueue' requested here
InJackPort() {
^
/Applications/Xcode_10.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/atomic:1087:8: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from 'int' to 'const std::__1::atomic<moodycamel::ReaderWriterQueue<EpsMidiMessage *, 512>::Block *>' for 1st argument
struct atomic
^
/Applications/Xcode_10.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/atomic:1114:23: note: candidate constructor not viable: no known conversion from 'int' to 'moodycamel::ReaderWriterQueue<EpsMidiMessage *, 512>::Block *' for 1st argument
_LIBCPP_CONSTEXPR atomic(_Tp* __d) _NOEXCEPT : __base(__d) {}
^
/Applications/Xcode_10.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/atomic:1112:5: note: candidate constructor not viable: requires 0 arguments, but 1 was provided
atomic() _NOEXCEPT _LIBCPP_DEFAULT
^
1 error generated.
Used Image: https://github.com/Microsoft/azure-pipelines-image-generation/blob/master/images/macos/macos-10.13-Readme.md
what’s Block? looks like it can’t find a constructor for it when using an atomic.
you should be able to replicate this under linux or windows by using clang++ instead of g++
Block is not my code, it is defined in readerwriterqueue.h.
I’d like to add something that may end up becoming required reading: http://atastypixel.com/blog/four-common-mistakes-in-audio-development/
it’s definitely high on my recommended reading list.
2 Likes
Iirc I tried to mention those issues in the paper I put up last year. Definitely stuff you don’t want to do. Thx for sharing.
1 Like
An interesting issue hapened to me perhaps related (or not) to this issue
I use blender (the 3d software) profesionally, and I have a very good desktop computer (Nvidia 1080 graphics I7 processor etc on linux ), a couple of days ago I installed the rack in that computer. I opened (a empty session , only core audio ) at the same time that blender and the graphics got a incredible lag like I never seen before in that computer (it remain me the windows2000 graphic lags) that issues is perhaps related to blendish?
Use a profiler and see for yourself. I can’t reproduce most people’s performance problems despite having 8 laptops now, mostly crappy ones from 2007-2014.
yes, it is the fist time that it happened to me too, it is a very particular case as I said, blender must be oppended
Oh yeah, running two OpenGL applications is usually not supported well with any graphics drivers. This is one of the reasons I disable multiple instances of Rack. Same reason that running two video games in simultaneously visible windows does the same thing.
1 Like
running two programs simultaneously that have high gfx requirements sounds… interesting?