3 ms·
>Where a traditional mutating UI framework would happily update a widget and keep CPU idle most of the time Is there a "traditional" UI framework that does thi
by nemothekid 4y ago
>Where a traditional mutating UI framework would happily update a widget and keep CPU idle most of the time
Is there a "traditional" UI framework that does this? Most UI frameworks are retained anyways and will build a tree (ex. Qt, Fltk); and will render at 60fps (or throttle is there is nothing to do). As far as overhead goes, I can't imagine the Rust approach being anymore expensive.
The approach of just updating and rendering a single widget is hypothetically more performant, but I rarely see it done in the wild due to how complex it can become as your UI gets more complex.
- int_19h 4y agoIt was the standard way to do native UI on the desktop before composition became common in mid-00s. I don't recall it being particularly complex in practice, especially when the frameworks abstracted most of it away. E.g. WinForms running on WinXP would still be doing this under the hood, but you as a developer could just set up data binding and write the painting code for any custom widgets (and wouldn't have to care about it getting called at the right time).