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

What Hacker News said

Strong rec raphlinus · 2018-09 · on “Using Rust for Game Development [video]”

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 th

Recommends exDM69 · 2020-11 · on “Dear ImGui – Bloat-free graphical user interface library for C++”

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 c

Cites vanderZwan · 2019-03 · on “Fast, Bump-Allocated Virtual Doms with Rust and Wasm”

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 swap

Cites exDM69 · 2020-04 · on “Puny GUI – A tiny cross platform GUI Kit in Janet”

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