Corrade / Magnum

[Daandelange]

Following up our discussion about using Corrade/Magnum or switching over to it. Let's start discussing this further. Official website

---

Magnum Community I've dived a little into Corrade+Magnum last week, it's a very interesting framework and Mosra's philosophy+coding style+explanations are awesome. Still he's the only main contributor but he seems very engaged/devowed, surrounded by a few punctual contributors. Magnum seems used by a few coders "internally", but recently some bigger public projects using it have emerged, including a research-ar-app sponsored by Meta, and the seemingly the semi commercial Wonderland engine.

OpenFrameworks vs Magnum Compared to oF, it really is a middleware as stated: it doesn't ship with lots of graphics utilities and those that are included are high-performance oriented. For my usage this is a good point, not sure about the global Mosaic scope if we want to keep the c++ code as accessible as in oF. The community seems smaller but active, there are less "integrations" (=ofxAddons). It's compiled using cmake by default, which OF isn't... it's not far from makefiles (a little obscure and rigid) but compiling multiple configurations becomes very flexible with it. Other compilers might be supported. I'm not sure how well both oF+Corrade would fuse together. Also, Magnum is very well namespaced which makes code really clean and reusable (more like Cinder compared to oF), on the other hand this makes coding new stuff less accessible to beginners (for example: you might get very verbose compile errors when you simply forget to include a header; in oF you simply #include "ofMain.h" and you're "safe"). Magnum currently is stripping out STL dependencies to prevent common c++ mistakes, for example by providing a set of containers adapted to real-time-graphics related computing, rather then trying to implement optimised version of stl containers... Just to illustrate how Magnum keeps optimisation and simplicity in mind. I've already learned a lot out of Magnum !

Mosaic + Corrade (+Magnum) There are a few interesting components in Corrade which could provide functionality in Mosaic that we are having difficulties to implement in Mosaic.

• Plugins There are multiple options to compile and load them (hardcoded, static, dynamic). I've already been able to draw to ImGui from a plugin, so that's a good sign. And their footprint is really small.

• Interconnect I'm not sure yet how the internal implementation is done, the syntax is very similar to the listener model (like in oF), but providing full type consistency and references (no pointers). We'll see if this is useful or not for out usage.

• Other ? Check out all available integrations here.

Then there's the question of what do we use in Mosaic and how do we implement it ?

• If we stick to oF, we'll probably use just Corrade (plugin manager + interconnect[signals+slots] + utilities).
• If we choose to release oF from Mosaic and switch to Magnum, I guess we'll have a stability gain, and maybe mosaic-plugins will still be able to integrate oF as a library, or we could provide an optional API for it. However, we'll lose ofxAddons which are quite a lot, but porting the non-graphical-ones to Magnum shouldn't be difficult.

Voilà some thoughts, to be followed :)

[sphaero]

I'm also curious about Corrade/Magnum but I haven't had time to take a dive yet. Is this a long term question for this project because of architectural ideas? Corrade/Magnum does seem very clean but also feels a bit a polished set of existing principals. (which is not bad). What I'm missing in corrade/magnum is abstractions for the parallel and concurrent needs. To me that's one of the most important properties for any future path. I'd also like to know how much it relies on the heap. As a reference the Ogre project also questioned once why it was not as fast as other engines and discovered it was because of its heap usage.

[Daandelange]

Hi Arnaud, thanks for sharing your thoughts. :)

To provide some background info: This "issue" started from a discussion between d3cod3 and I, about future development plans and that at a give stage, we'll probably need/want to step away from OpenFrameworks as base engine. Because of various reasons, mainly to keep our own engine minimal and standalone, but also because OF is starting to feel old (old school build systems, stuck to GLFW windows, no Vulkan, huge code base and compile times). Right now the big pros of OpenFrameworks are that we are both familiar with it and there's a huge community with lots of addons which are easy to hookup. Also, as we still have plans of refactoring the "wirings", Magnum also looks like a great candidate for using the Interconnect API.

About your worries about parallel and concurrent needs, I'm still not very familiar with it (neither is d3cod3, I guess), even after reading some of your papers and presentations, that's your domain! Correct me if I'm wrong, it's about multithreading and/or distributed computing across multiple devices, right ? Could you provide a deeper insight ? How will it make Mosaic better ? Some example case ?

Same for the heap, do you have a reference for Ogre+heap issues ? I'd be interested to read about it.

[sphaero]

Hi Daan. There was a talk about it once but I can't find it anymore. I have been researching the concurrent issues but it's really hard as it involves deep knowledge about issues with multithreading and what the hardware is doing. Easiest I've found is message passing which also fits the 'wirings'/visual coding paradigm. However it will never be as performant as good old sequential coding. Best is to mix them.

However there are other insights which are more data-oriented in which you push data through a processing pipeline. The processing pipeline can then utilize as many cores as possible. This fits the dataflow paradigm better (like puredata) and I think Unity was working on that with their burst compiler

[sphaero]

Hope you don't mind me sharing some of the things I'm working with. As you might know I'm looking into how to utilize multiple threads in easy performant way. The biggest issue I face when implementing an architecture for this is drawing on screen from multiple threads. It could be done using a message passing paradigm but OpenGL wasn't meant for this. The new kid in town is Vulkan. I'm still looking into this. Here's a nice guide which explains it well including more in-depth links: https://vkguide.dev/docs/extra-chapter/multithreading/ It's very C++ oriented however.