Update and view being systems

[kulkalkul]

I've checked how update and view works in iced. They do not run unless user acts. Update iterates over bevy event, so I don't think that has any overhead. But view recalculates each frame as it is a system and that feels wrong.

Thinking about it, most bevy way of doing it could be using run conditions. Other option would be removing the system and using a struct just like how iced does and with systems to propogate updates or run view function. Then that struct could decide to recalculate view or use cached one.

What do you think? Btw, I'm spamming with issues but I hope you are available. 😅 I could experiment with it if you are busy.

[focustense]

I rather like being able to use the immediate-mode style despite iced being a retained-mode framework. My rationale, for what it's worth, is as follows:

• Iced already diffs the widget tree to avoid layout (always the most expensive operation) so the impact on frames is insignificant. With a few thousand widgets on screen I don't see more than a ~0.5% jump in CPU usage.
• Command buffers in wgpu are (I believe, but don't quote me) also diffed per frame, so not only is the drawing being done on the GPU, but if there is some expensive drawing operation, like rendering a large texture that changes infrequently, then it also has no repeating cost. OpenGL tossed the old display list concept but Vulkan et al brought it back, sort of.
• Updates in Iced are based on Events, but cleanly correlating events to view/widget updates is difficult to do in an ECS environment because it assumes either a single monolithic UI state (which is literally fighting Bevy on its own turf) or the ability to delegate to different shells and windows, which bevy_iced doesn't support.
• UI updates in games don't happen exclusively as a result of user interaction; there are all sorts of things happening in the background that need to update the health bar, inventory, HUD, stats, etc., regardless of whether you've pressed a button or moved the mouse. Even modern desktop apps tend to support background processing - which of course can be handled fine with programmatically-triggered Iced events, but in a desktop app there will be relatively few of these events whereas in a game ECS that number is going to explode. That is unless you take the shortcut of defining a generic UpdateUI type of event, which you are likely going to end up sending almost every frame anyway, like the Solar System example which just sends constant Tick events.
• If you were willing to take on the burden of defining micro events for UI updates, presumably they'd be triggered based on Bevy's change detection; but change detection is more expensive than people think. Unless your system is actually doing something very costly, like loading a 3D asset or running enemy AI, it's often counterproductive to use a Changed query because it's more expensive to check each entity for changes than it is to just for_each it. It all depends on your particular game, of course, but determining whether or not you need to recreate the UI tree is often counterintuitively more expensive than just recreating the UI tree.
• Combine the above with the fact that a single UI widget is likely to be aggregating information from several different entities or entity hierarchies, and determining whether or not anything "changed" can quickly turn into a very complicated and expensive process. This is undoubtedly why ImGUI was and still is such a popular choice in games.

I'll admit, it feels a little like we're abusing the iced library, hooking directly into its layout and rendering systems and bypassing the entire "front end" API, and maybe over time the vision of iced will diverge too much for this "immediate iced" to be maintainable - but for now, it handles that without even breaking a sweat, and the more recent work on the iced library points toward, not away from, support for "just the widgets" or "just the renderers". They are all distinct sub-crates now.

So, yes, bevy_iced is iced without Applications or Shells, and that also means (more or less) without the normal update cycle; the ECS takes their place, and that's A-OK as long as the renderer can keep up. If you really don't want anything to run except when there's user input, that's what WinitSettings::desktop_app() is for.

[tbillington]

@focustense does the iced project know about this use case? It would be sad if they didn't and made some architectural change that prevented this mode of use from working if it could have been avoided.