Data Oriented GUI in Rust by Raph Levien - Bay Area Rust Meetup

I found this excellent talk to be complementary to my talk[1] on data-oriented GUI in Rust, not to plug my own work too much. I found a lot of common ground: * Trying to write object-oriented code in Rust doesn't work well. Writing data-oriented code does. * "Fighting the borrow checker" is a sign you might be doing it wrong. Try data-oriented approaches instead. * Use a structure-of-arrays rather than an array-of-structures. * Use what I call "state splitting" to borrow mutable references to just the state you need; this works well with the structure-of-arrays approach and is a powerful motivator to use it. * To build graph-like structures, reach for a Vec of components, and indexes into the Vec for relationships, as your first choice. Self-references, arena allocators, and Rc are viable alternatives, but you should have a good reason to use them instead of Vec. * Some form of dynamic typing is useful to keep your system loosely coupled (though we ended up with very different forms of dynamic typing, see below). * Data-oriented approaches have taken root in the C++ gaming community, mostly motivated by performance, but adapt well to Rust, and some of the ideas may be useful in domains beyond gaming. There were some other points that went beyond what I talked about, but could fit in well: * A "generational index" is a good way to avoid use-after-free style errors that result from the use of a stale index. The slotmap crate can help. And now for the things that are different.

in “Using Rust for Game Development [video]” · View on HN

As much as I like Dear ImGui, the immediate mode paradigm doesn't work everywhere. The problem of "page tearing" (not to be confused with vsync) means you either need to render frames continuously, or at least 2 frames for every time you get input or need to implement some kind of "retained mode state tracking" on top of Imgui. It's good for games, but for applications where you're not rendering new frames constantly, the paradigm doesn't seem a very good fit. I wish there was a retained mode GUI library that would be as easy to integrate in your game and graphics apps as ImGui (or nuklear) is. On my spare time, I've been working on a retained mode GUI layout and rendering framework (not a complete GUI toolkit) that uses a DOM-like tree, CSS style flexbox layouts and produces a vertex buffer for rendering like ImGui does. Unfortunately life gets in the way, and all I have to show for my project is a small prototype in C and another one in Rust (can't decide which I like more) that draws some text and rectangles with a fancy layout. Code is not public at the moment but I'm willing to share it with anyone (on GitHub) who responds with a thoughtful comment or a good question. I have been following Raph Levien's fantastic work on Druid and Rust GUIs which has been very inspirational, this video in particular [0]. Where Raph is focused on native GUI rendering and high fidelity text output, I've only focused on rendering in a GPU application using shaders and only very basic text l

in “Dear ImGui – Bloat-free graphical user interface library for C++” · View on HN

I haven't shared the code in public but if you give your GitHub username, I can share it to you (and others who are interested) and you can reach out via email (address in commit log). I got inspired by Raph Levien's talk on Rust and GUI layout [0] and realized that a simple flexbox layout algorithm can be implemented really efficiently. So I started making a prototype in C (also a small proto in Rust), using a densely packed array to implement a DOM-like tree. The tree nodes have short strings, boxes (with border, padding, etc), images (texture coordinates in an atlas), layout constraints, containers, etc. Flexbox layout is applied to the tree in linear time (and constant memory!) and then the tree is traversed to output an ordered list of axis aligned rectangles. The output list can be fed to the GPU, where a special (but simple) shader draws clipped triangles that get applied with textures, msdf font, etc. The whole GUI gets rendered with a single draw call. This all can be done with very fast performance (sub-millisecond for layout and rendering, excluding GPU latency). There are other implementation details that make it efficient for cache (sizeof(node) == cache line), no recursion, no memory allocation, no unbounded loops, no system calls, etc. I'm fairly convinced that this approach should be enough to cover 80% of modern GUI paradigms. However I don't have the time or the interest to build a complete widget set GUI library. Right now I'm sporadically working on the pr

in “Puny GUI – A tiny cross platform GUI Kit in Janet” · View on HN

Thanks! Looks very interesting, going to watch the video about Druid linked in the README.MD later[0]. And no worries, it's very easy to forget not everyone is introduced! Anyway, to actually engage with your point: I can see the appeal of an all-Rust framework: good typing system + high performance (both in speed and low memory use, ideally) sounds fantastic! So out of curiosity: how do you think hot swapping would be handled? I'm asking this who has not dived into Rust at all and only observed it with interest from a distance. For starters, I understand Rust has fairly slow compilation times, no? Or is that only true for optimized code and do we have fast debug options? Similarly, hot swapping requires maintaining state. With JS that's not too difficult because you don't worry about memory layout: as long as the high-level structure and names are the same the code works fine (it just kills the JIT optimizations). With WASM, that goes out the window: add or remove a field to your struct and all offsets change. Rust may guarantee no memory leaks, but that is not the same as guaranteeing that a snapshot of the memory state of one Rust program works on a different one. I guess some kind of "export to/import from JavaScript based representation" glue code that runs every hot reload could work, but that sounds like it could really freeze the browser when hot-reloading the big frameworks. [0] ▶ this video would be funny if I forgot to include links myself at this point :p

in “Fast, Bump-Allocated Virtual Doms with Rust and Wasm” · View on HN