[Iced was built during May] using the 0.2 version of [stretch]. It seems that a new minor version was released recently, in July. We should consider upgrading.
At a first glance, the API has changed somewhat considerably. There is a new Stretch type that you have to keep around and mutate accordingly. I am guessing this allows (or will allow) for incremental computation of layouting, which is great!
However, in order to mutate the Stretch type and keep it in sync, we will need to implement a diffing strategy of nodes. This is mostly a solved problem, as React and Elm already do it, but some research will certainly be necessary and we will probably need to change the API a bit.
Also, as a naive first approach, we could simply recreate the Stretch type entirely every time.
In any case, benchmarking before upgrading is a good idea.
hecrj
>All comments
As I'm probably to blame for this new API, it was mostly motivated by reusing memory and nodes across changes. The author seems to be interested in more incremental relayouting possibly in combination with salsa but that's currently beyond me!
Issues, performance numbers and general feedback appreciated!
msiglreith
on 5 Sep 2019
Related issues
Newbytee
路
4Comments
Shootertrex
路
3Comments
cetra3
路
3Comments
johannesvollmer
路
4Comments
Plecra
路
4Comments
Most helpful comment
As I'm probably to blame for this new API, it was mostly motivated by reusing memory and nodes across changes. The author seems to be interested in more incremental relayouting possibly in combination with salsa but that's currently beyond me!
Issues, performance numbers and general feedback appreciated!