> 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. 

Reply via email to