3 ms·

It was a top contender when I was picking a GUI solution but it didn't meet the cut. Remember that this was 3.5 years ago. The decision to go with HTML/CSS was

by Keavon 2y ago

It was a top contender when I was picking a GUI solution but it didn't meet the cut. Remember that this was 3.5 years ago. The decision to go with HTML/CSS was undoubtedly the right one and it'll continue to treat us well for the foreseeable future. But we are beginning to rewrite certain areas, like the node graph, in our own render stack because this streamlines the code best. And other widgets like histograms, color scopes, etc. will continue to be built with our own renderer. And then at some point, it will start making sense to begin gradually replacing other parts of our UI with the regular widgets like buttons and checkboxes with that system. Doing so will help us simplify things and make them more user-customizable, so plugin authors can affect the UI, etc.

adastra22 2y ago
I sincerely doubt you will be able to match the performance of native widgets with immediate-mode render libraries.
airstrike 2y ago
It's your app, so obviously do whatever you want, but I agree with the sibling comment that an immediate mode GUI wastes valuable CPU cycles redrawing the frame repeatedly and will invariably hurt performance Again, since iced is "just rust", you can write whatever widgets you need, although it comes with a long list of built-in widgets (and there are many more built by the community). You can compose views with a bunch of these widgets to get to the UI you want. There's also nothing stopping you from creating a way for users to write widgets for your iced application. The sky is the limit. And I'm singling out iced because I'm a fan, but this should be true for pretty much all robust GUI toolkits out there.
- adastra22 2y ago
  Isn’t iced immediate mode?
  - airstrike 2y ago
    No, it's a bit of a mix. Retained until some update is processed by the runtime which causes the widget tree to be rebuilt, in which case it gets diff'd and stale widgets get replaced. Some widgets always redraw though, like Canvas, but they expose caching functionality I'm no authority here but that's the gist of my understanding

by Keavon 2y ago

adastra22 2y ago

I sincerely doubt you will be able to match the performance of native widgets with immediate-mode render libraries.

airstrike 2y ago

It's your app, so obviously do whatever you want, but I agree with the sibling comment that an immediate mode GUI wastes valuable CPU cycles redrawing the frame repeatedly and will invariably hurt performance Again, since iced is "just rust", you can write whatever widgets you need, although it comes with a long list of built-in widgets (and there are many more built by the community). You can compose views with a bunch of these widgets to get to the UI you want. There's also nothing stopping you from creating a way for users to write widgets for your iced application. The sky is the limit. And I'm singling out iced because I'm a fan, but this should be true for pretty much all robust GUI toolkits out there.

adastra22 2y ago
Isn’t iced immediate mode?
- airstrike 2y ago
  No, it's a bit of a mix. Retained until some update is processed by the runtime which causes the widget tree to be rebuilt, in which case it gets diff'd and stale widgets get replaced. Some widgets always redraw though, like Canvas, but they expose caching functionality I'm no authority here but that's the gist of my understanding