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

I found this excellent talk to be complementary to my talk1 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…

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…

…way more advanced and polymorphism via subtyping is now sort of replaced by parametric polymorphism with a ducktyping or in Rusts case with traits (which is like in between ducktyping and subtyping mixed with OOP-mixins). Where OOP really shines is still in GUI. Here is a great talk about GUI and Object-Oriented-Desing vs Data-Oriented-Design: link to this video Edit: And OOP - at least to Alan Kay - is not what most people think it is. Yeah I'm myself guilty as I have 'misused' the term here too. Neither classes nor inheritance are mandatory for OOP. Good examples for OOP would be Smalltalk and Erlang while a bad one would be C++ as Mr. Kay stated himself "Actually I made up the term "object-orie…

…, 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 link to this video would be funny if I forgot to include links myself at this point :p…

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…