> Their approach is to use a native GPU-rendered context, using either wgpu or > tiny-skia (based on the widely-used Google 2D canvas project called Skia), > and provide a set of controls which can be themed and adapted for various use > cases.
Fidget runs this way. It runs into performance issues when you create lots of "nodes". Figuro builds on the Fidget model and makes it multi-threaded. So the UI nodes are created on another thread and sends "render" nodes to the backend which uses Pixie, OpenGL, and Windy. > Would this not be an ideal approach for Nim? Maybe we don't have to exactly > adopt the Elm-style functional-reactive application model (then again maybe > we should!), but the foundational idea of rendering a GUI context in a > platform-agnostic canvas-based accelerated manner is profoundly useful. I think so! :) The downside of creating your entire rendering and everything is needing to create the event system and theming, etc. I haven't worked much on Figuro lately as I've been busy with other things. Though last week I fixed a big memory leak in how the event system works. However, the backend multi-threaded rendering setup in Figuro could be used by an alternative "UI layer" using the "render" nodes. It'd take little refactoring, but it's only a couple of procs that can be used. Note there's some limits in Windy and multiple windows and keyboard events, etc. Those are crucial to the ecosystem IMHO too.