A talk that would make Mike Acton proud. :) I find it interesting that a lot of modern GUI frameworks are borrowing a lot of principles from game programming. Good stuff. Thanks for the talk.
I'm looking at that UiState thing... there's a vec of boxes of dyn stuff.... that will need an allocation for every new widget; then those are going to be scattered around in memory (I suppose jemalloc helps somewhat); and then there's going to be a double pointer dereference needed to get to both data and behaviour... I have to ask: do u even cache m8?
@@batlin if you cared about caches you would layout widgets of the same type together and keep their data small enough to fit in cache (or make the widget data itself SoA so you can pick which system uses which data). Jumping around in memory randomly is the opposite of data oriented design. IMO there is no good way to write generic toolkits that are "data oriented" because the data layouts would depend on which widgets are actually used in your app and how you update them. I wish people would stop equating ECS architecture with data oriented design. ECS is just one architecture that solves a specific subset of problems in games.
@@KiranPurushothaman You could do a custom allocator that allocates widgets next to each other despite being different sizes (which you would store next to each widget). I'm still a Rust newbie, so I'm not sure how you'd do that, but in C++ it's definitely possible. You would get very good caching since all your related widgets (i.e children) would be next to each others, however this makes for a very very complicated system, no random access, difficult to insert/remove elements ...
@@wegreenall well, in theory, “data oriented design” sort of implies that the programmer would try to make their data cache-efficient. In practice, it really does depend on how *often* the objects need to be fetched from distant caches and/or main memory. If you load an object and keep it around for a while, it might not make a huge difference.
Not sure what the best is, but druid is good for simple custom widgets, iced is another elm-based one, and tauri is great if you want to turn a web-app into a desktop app
I know this is four years old, but if that was the status then, Rust still have a long way to go. You expect any modern language to have a complete and tested GUI toolkit.
I don't know of any language that has a GUI toolkit, except Delphi and Browser based JS. It's not a language feature and never should. At the moment there is unfortunately not even a good toolkit. MacOS is in the huge swift - swiftUI rework, GTK 4 is buggy and Win UI3 is a sad joke, Qt shows that there is no interest and even Android is not there as it is too simple for large screens (Android 12L release showed that)
@@llothar68 Java (AWT + Swing) and C# (Windows.Forms) are the big 2 with standardized GUI libraries. We will likely never see and should never see a STL GUI for C, but I would like to see one for C++ and/or Rust in the future. It's about damn time that technology standard (platform specific) features like sockets/networking/encryption and graphics start becoming language features. In C++ we already have , , libraries. In Rust, there's std::thread, std::fs, and std::ops::Generator.
A talk that would make Mike Acton proud. :)
I find it interesting that a lot of modern GUI frameworks are borrowing a lot of principles from game programming. Good stuff. Thanks for the talk.
That's only logical actually. Video games are just interactive graphical media, sounds a lot like a GUI.
@@nextlifeonearth The main difference being that games try to maximise the hardware usage, where GUIs try to minimise the hardware usage.
@@jack-d2e6i I would say both are trying to use hardware as efficiently as possible
@@jack-d2e6i not exactly true
games try to maximize the efficiency of their hardware usage
Great talk. Great idea to make a separate video per talk in the meetup.
I'm looking at that UiState thing... there's a vec of boxes of dyn stuff.... that will need an allocation for every new widget; then those are going to be scattered around in memory (I suppose jemalloc helps somewhat); and then there's going to be a double pointer dereference needed to get to both data and behaviour... I have to ask: do u even cache m8?
What do you think would be a nicer alternative?
@@batlin if you cared about caches you would layout widgets of the same type together and keep their data small enough to fit in cache (or make the widget data itself SoA so you can pick which system uses which data).
Jumping around in memory randomly is the opposite of data oriented design.
IMO there is no good way to write generic toolkits that are "data oriented" because the data layouts would depend on which widgets are actually used in your app and how you update them. I wish people would stop equating ECS architecture with data oriented design. ECS is just one architecture that solves a specific subset of problems in games.
@@KiranPurushothaman You could do a custom allocator that allocates widgets next to each other despite being different sizes (which you would store next to each widget).
I'm still a Rust newbie, so I'm not sure how you'd do that, but in C++ it's definitely possible.
You would get very good caching since all your related widgets (i.e children) would be next to each others, however this makes for a very very complicated system, no random access, difficult to insert/remove elements ...
Are there really going to be enough widgets that it makes a difference? or is this a question of good technique?
@@wegreenall well, in theory, “data oriented design” sort of implies that the programmer would try to make their data cache-efficient. In practice, it really does depend on how *often* the objects need to be fetched from distant caches and/or main memory. If you load an object and keep it around for a while, it might not make a huge difference.
About line granularity redraws: What if you have unicode characters that extend over a line? (I know many text editors cut that off.)
Great presentation!
that cube mic is awesome
what is the best GUI tool kit right now in rust . ?
Not sure what the best is, but druid is good for simple custom widgets, iced is another elm-based one, and tauri is great if you want to turn a web-app into a desktop app
Here's a link to the slides: docs.google.com/presentation/d/1aDTRl5R-icAF38Di-qJ4FzAl3pLlutTKVFcr3mUGgYo/edit#slide=id.p
thanks!!!
I would have prefered more graphics and less text on the slides.
@Dzmitry Lahoda docs.google.com/presentation/d/1aDTRl5R-icAF38Di-qJ4FzAl3pLlutTKVFcr3mUGgYo/edit#slide=id.p
It's a technical presentation about a specific piece of code. Of course it's mostly text.
I know this is four years old, but if that was the status then, Rust still have a long way to go. You expect any modern language to have a complete and tested GUI toolkit.
I don't know of any language that has a GUI toolkit, except Delphi and Browser based JS.
It's not a language feature and never should.
At the moment there is unfortunately not even a good toolkit. MacOS is in the huge swift - swiftUI rework, GTK 4 is buggy and Win UI3 is a sad joke, Qt shows that there is no interest and even Android is not there as it is too simple for large screens (Android 12L release showed that)
@@llothar68 Java (AWT + Swing) and C# (Windows.Forms) are the big 2 with standardized GUI libraries. We will likely never see and should never see a STL GUI for C, but I would like to see one for C++ and/or Rust in the future. It's about damn time that technology standard (platform specific) features like sockets/networking/encryption and graphics start becoming language features. In C++ we already have , , libraries. In Rust, there's std::thread, std::fs, and std::ops::Generator.