3 ms·
I don't think you can meaningfully use immediate-mode GUIs for anything related to compositing work. If you're creating debug UIs or basic UIs at best, you're
by andrewmcwatters 3y ago
I don't think you can meaningfully use immediate-mode GUIs for anything related to compositing work.
If you're creating debug UIs or basic UIs at best, you're fine. That might actually work out alright for DAWs, but if you want sophisticated user-interfaces where you can add effects to things, you need to start retaining graphics data, and so many people advocating for these old school immediate-mode GUI libraries just don't get that.
- truckerbill 3y agoCan you explain this point a bit more? I've always hated retained mode GUI systems and im-guis seem so much nicer to work with. But I've not made something huge with them. What do you mean by compositing in this context?
- pkphilip 3y agoImmediate mode gui - psuedocode where volumeSlider is a slider used for setting the audio volume and spectrograph includes a bar which displays the volume visually: function volumeSlider_onChange() { audioEngine.setVolume(volumeSlider.value); spectrograph.setVolume(volumeSlider.value); } function stopButton_onClick() { audioEngine.getCurrentTrack().stop(); } function audioEngine_statusCallback(Track track) { spectrograph.update(track.status); } To do something like this in a declarative UI, you will need some sort of a state machine, that state machine will then need to have a bunch of state variables, callbacks/hooks, providers/notifiers etc. And you have to have this managed for each variable. That is, there will be a LOT more code that needs to be run before updates flow from the GUI to the engine or from the engine back to the GUI. Why would you think that declarative UI will be more efficient?