Thanks for looping me in to this thread, @jntrnr. Reading through it, I have a few thoughts.
First, an explicit goal of xi-win is what I’d describe as “uncompromising performance.” To me, this means not repainting the whole screen just because a GPU can do it in a small number of milliseconds, not creating make-work intermediate representations, etc. It’s a separate question whether this is the right point in the space, but at the very least I want to understand what’s possible and how hard it is to actually achieve. I’m finding that performance is an interesting problem, and I’ll have more to say about it as I build it out (note that I’m not making strong performance claims about the existing prototype, it takes a number of shortcuts).
The next observation is that I’m finding that modern UI is often quite layered, as exemplified by Flutter. At the top layers, you want to have a discussion whether you’re using a Flux-style functional reactive pattern, some kind of declarative approach, a DSL of some kind, or whatnot. At the lower levels, you want to be concerned about whether you’re effectively using the GPU resources, avoiding redundant work when the deltas are small, etc. In between, you have some really difficult questions around, for example, how to decompress images off the main thread speculatively, before they scroll into view. Of course, imgui is something of a reaction to the layered approach. From my perspective, imgui makes tradeoffs that are more suitable for a game than a traditional productivity-style app.
I’m explicitly only addressing the lower layers in my prototype. I think it’s also very much worth exploring the question, “what is the most concise, idiomatic expression of some UI in Rust?” Then as a separate question how to map it to an incremental widget tree implementation, which I think is still the gold standard for performance and ability to do things like accessibility and responsive layout.
I don’t claim to have the answers, but I hope my prototype is interesting input to the discussion.