3 ms·

Yup, and I strongly suggest option 1, just take the perf loss. You can probably detect in each of your state update functions that nothing changed and just reus

Yup, and I strongly suggest option 1, just take the perf loss. You can probably detect in each of your state update functions that nothing changed and just reuse the previous result (a memcpy is pretty fast, or if that data is in a separate allocation just copy the pointer). The same is true of the functional core idea really, you're still going to have a big tree of function calls rebuilding things unless you also add some memoization to it. React and friends do it because DOM manipulation is very slow. But think of IMGUI style GUIs, they're rebuilding the entire user interface every frame and yet are often more efficient than many retained mode UIs. Redundant computation is not as bad as it sounds at first glance.

geokon 4y ago
I asked around and there is another option. Something called "Incremental Computations". Here is a Clojure library. I think the examples kinda demo how it works https://github.com/hoplon/javelin https://github.com/hoplon/javelin It's sort of a version of option 3
kaba0 4y ago
> and yet are often more efficient than many retained mode UIs I don’t know what metric you use for that, but they are definitely not more energy efficient — retained mode is a must for any battery-powered device.
- sirwhinesalot 4y ago
  I meant computational efficiency, highly dynamic UIs usually perform a lot better as immediate mode GUIs since there are less indirections and memory allocations going around. If you're rebuilding things a lot anyway, it's actually more efficient to just accept that rather than work around it. Though speaking of immediate mode UIs, I think a lot of the problem there is that most of the immediate mode UI libraries assume they're being used as the user interface of a Game or 3D render application which needs to render a complex 3D scene regardless, so who cares about the extra 400 microseconds the UI takes to render. You could imagine optimizing immediate mode UIs quite a bit for energy efficiency by not redrawing anything if there's no use input, or selectively redrawing dirty areas where it makes sense.
  - kaba0 4y ago
    > You could imagine optimizing immediate mode UIs quite a bit for energy efficiency by not redrawing anything if there's no use input, or selectively redrawing dirty areas where it makes sense. That’s pretty much what a retained-mode UI does.
    - sirwhinesalot 4y ago
      I don't mean doing it in a retained-mode-like way with a data structure in memory, I mean special casing certain UI elements. For example, a blinking cursor could be a special path through the code which updates only the pixels where the blinking cursor is, while the rest of the window just reuses the last drawn frame (kinda like how mouse cursors are handled in hardware). Similar tricks work for things like hover highlights and context menus. No need for a retained data structure to implement the above.

geokon 4y ago

I asked around and there is another option. Something called "Incremental Computations". Here is a Clojure library. I think the examples kinda demo how it works https://github.com/hoplon/javelin https://github.com/hoplon/javelin It's sort of a version of option 3

kaba0 4y ago

> and yet are often more efficient than many retained mode UIs I don’t know what metric you use for that, but they are definitely not more energy efficient — retained mode is a must for any battery-powered device.

sirwhinesalot 4y ago
I meant computational efficiency, highly dynamic UIs usually perform a lot better as immediate mode GUIs since there are less indirections and memory allocations going around. If you're rebuilding things a lot anyway, it's actually more efficient to just accept that rather than work around it. Though speaking of immediate mode UIs, I think a lot of the problem there is that most of the immediate mode UI libraries assume they're being used as the user interface of a Game or 3D render application which needs to render a complex 3D scene regardless, so who cares about the extra 400 microseconds the UI takes to render. You could imagine optimizing immediate mode UIs quite a bit for energy efficiency by not redrawing anything if there's no use input, or selectively redrawing dirty areas where it makes sense.
- kaba0 4y ago
  > You could imagine optimizing immediate mode UIs quite a bit for energy efficiency by not redrawing anything if there's no use input, or selectively redrawing dirty areas where it makes sense. That’s pretty much what a retained-mode UI does.
  - sirwhinesalot 4y ago
    I don't mean doing it in a retained-mode-like way with a data structure in memory, I mean special casing certain UI elements. For example, a blinking cursor could be a special path through the code which updates only the pixels where the blinking cursor is, while the rest of the window just reuses the last drawn frame (kinda like how mouse cursors are handled in hardware). Similar tricks work for things like hover highlights and context menus. No need for a retained data structure to implement the above.