makepad VS magnum

It is what Makepad is working on in an interesting way using Wasm and Rust. They have created a Figma-like DSL and a good code separation with the logic behind it. You can edit UI's of in-production apps, and they are bundling an editor for that. Accessibility is an issue, and the project are looking to offer proper support there. In their video linked on the README they run the conference slides on Makepad with live apps embedded and running at 120 fps.

https://github.com/makepad/makepad

https://news.ycombinator.com/item?id=36567681

> if anyone tells you they need to use WebAssembly to make the UI snappy I'd advise you interrogate that assertion thoroughly.

Get prepared to be blown away by Makepad [0]. I have no affiliation with them, but just watched their most recent conference presentation [1]. The slides were made with Makepad itself and included, embedded, a full-blown IDE, a synthesizer app, a Mandelbrod to zoom in endlessly, and more. All running at 120fps. The presentation is for the most part live-coding with this setup.

What they want to do is bring coders and designers closer together, and while some code is in Rust they developed a DSL for the GUI parts that is close to how Figma works. These GUI's can run anywhere.

And I couldn't help thinking "Why would people have complicated stacks to create Web 2.0 apps for the Google Web, when they have this?", in other words an opportunity to break out of the browser straitjacket.

[0] https://github.com/makepad/makepad

[1] https://www.youtube.com/watch?v=rC4FCS-oMpg

For those who haven’t seen it, Makepad is also an in-browser code editor with an open-source UI toolkit. Looks like this synth is one of the examples of the UI toolkit.

https://makepad.dev/

And I'm obsessed with what happens when you press Alt in their editor. I never knew I wanted this, but boy, do I want it.

I tried this, using https://makepad.dev our GPU accelerated UI and renderstack. And unfortunately it wasn't a great experience. Text popping forward for whatever reason is not really an improvement (i tried indent depth, syntax highlighting reasons, cursor behavior). Maybe 'veeeeery' subtly could do something, but otherwise you dont want it to break visual symmetry as we are used to

Wow, so they did: https://github.com/makepad/makepad/pull/142

It says on the front page Mac and Web only

https://github.com/makepad/makepad#prerequisites

(windows and linux are coming )

We can! It’s a lot of work because you don’t have the whole JS ecosystem to fall back on, but to some that’s a feature not a bug.

My favorite example of this is https://makepad.dev

And a feature highlight of Code Lens. The idea is borrowed from https://github.com/makepad/makepad

When it comes to compile times, the most optimized Rust codebase I know for optimized for this is makepad.dev [1].

It is compiling from scratch on mac m1 in around 7.5s [2] and that's +100k lines of Rust. However there is close to none dependencies, so this +100k is all there is to compile pretty much.

[1] https://makepad.dev/

[2] https://twitter.com/rikarends/status/1467529091284934666

Magnum

If you want something that gives you more control you could use magnum.

Therefore, in terms of artist mindshare, Blender is the leading open source 3D creation program, but not the leading 3D creation program. I think Godot is already in a similar situation, and has been for a few years now. In comparison, most other open source game engines have focused on providing low-level functionality. These certainly fulfill a niche, but in my experience, most people want something that works at a higher level and comes with a built-in editor.

Magnum is worth checking out.

Since you want something lightweight, I'll assume you mean the former. If that's the case, then checkout bgfx or Magnum. Magnum does include some extra features typically found in a graphics engine.

You could try Magnum it wraps SDL and others, but you might find it maybe too low-level. It's certainly not Love2D.

C++ is similar to C in that there are multiple "styles" of use that vary from project to project. Other, usually newer languages (C#, Python, Rust, etc) tend to have a stronger sense of what idioms should be used. Whereas, for instance, some C++ projects (like some GUI libraries and game/graphics engines) will partially/entirely replace the STL (and older ones may have been around before C++ had a standard library aside from C's), or forbid the use of certain C++ features (example).

Magnum Graphics

> He has Vulkan support in here with a clearly marked file named Pipeline.cpp. The guy knows what a pipeline is...

There is a Vulkan API wrapper. However, there is no "Vk Renderer" -- no code seems to use the Vulkan parts of the code system, and the two projects seem unrelated.

> * Is this not a UBO interface?

There are ways of making a uniform buffer, however the examples don't cover them and the API doesn't adapt automatically. See how all of the setters assert if UBOs are enabled.

https://github.com/mosra/magnum/blob/cfc02599e54e02337dd56bb...

> * I don't see why you think there's limited support for multiple framebuffers...?

The code I do see is about binding/unbinding framebuffers in a stateful manner, e.g. AbstractFramebuffer::bind(), rather than supporting passes.

> None of your criticism seem well intentioned. It might behoove you to give people the benefit of the doubt and realize that you may be able to learn something from them, even if they're so clearly inferior to you.

To put it simply, I've taught enough graphics to know first-hand the kinds of misconceptions that OpenGL-styled APIs can cause, and I'm just a bit tired to see it continue. Admittedly I was a bit harsh, I don't mean any harm towards the author. There are just graphics APIs with interfaces I consider to be much better designed.