Custom layout engine

[hecrj]

This PR drops the stretch dependency and implements a custom layout engine based on the druid codebase, which is in turn inspired by Flutter. The main reasons for this change are simplicity, intuitiveness, and performance.

Flexbox, while powerful, is hard to use properly. Many of the styling properties of a flex node are tied to the parent flex-direction. This makes specific constraints very hard to encode (fill width/height, horizontal/vertical alignment, etc.). I think specific constraints like these are the ones users care about in the end.

Additionally, stretch forced us to turn every single node of the layout system into a flex node. This meant that even very simple nodes that did not have complex layout needs would still be seen as complex flex nodes by the layout algorithm.

Furthermore, we were using an old version of stretch and upgrading was not straightforward (#4). The upgrade would have entailed keeping a Stretch type around and mutating it as layout changes.

Moreover, computing layout with stretch was very slow. On my system, computing the layout of the "Text" screen in the tour example took around 4 ms. I think this could be related to using an old version and some odd behavior that I had to work around.

---

The new layout engine is very straightforward: each Widget is in charge of computing its boundaries inside the provided layout::Limits.

This way, complex widgets like Column and Row can distribute contents in a flex-like way, while simpler widgets like Button perform simple computations.

The new system is way faster. During my testing I have noticed a speedup of around 2 orders of magnitude in the best case (text measure cache hits) and 1 order of magnitude in the worst case (text measure cache misses). For instance, the "Text" screen I mentioned before now takes around 40 μs in the best case and 100 μs in the worst case. Debug mode is actually usable now! 🎉

In addition, a new Container widget has been added, allowing us to perform both horizontal and vertical alignment without the need of a "direction". Because of this, the Justify type has been dropped. Align will most likely change too.

Finally, the changes have been mostly internal. All the examples should be working as before!

Closes #4.

Changelog

Added

• Container widget which allows easy alignment with methods like center_x and center_y
• Widget::width and Widget::height, which should be implemented properly by widgets.

Changed

• The flexbox layout engine has been replaced with a simpler, more intuitive alternative.
• Widget::node has been changed to Widget::layout and it now computes the boundaries directly.
• max_width and max_height methods now take a u32 instead of a Length.

Removed

• stretch dependency
• Justify type, justify_content and align_self methods

[Matthias-Fauconneau]

Nice work !
Maybe it might be a good opportunity to clarify the difference between iced and druid ?
I chose iced because it seemed more ready, based on the tour demo and native rusty backends (winit/wgpu) while druid seems to be still an early experiment (and gtk backend :().
What would the front-end difference be between 'Elm-inspired' and 'data-oriented' ?
Maybe also other design philosophies ?

[hecrj]

@Matthias-Fauconneau Thanks!

Maybe it might be a good opportunity to clarify the difference between iced and druid ?
I chose iced because it seemed more ready, based on the tour demo and native rusty backends (winit/wgpu) while druid seems to be still an early experiment (and gtk backend :().
What would the front-end difference be between 'Elm-inspired' and 'data-oriented' ?

Have you read both the READMEs of iced and druid? I think they both explain their particular approach to GUI design quite well! I also recommend you to check the examples, which can help you get an idea of how different things are done in each library.

[Matthias-Fauconneau]

I read both, maybe I'm just not familiar enough with modern UI architecture. I am suggesting presenting the contrasts more explicitly could be useful to newcomers who need help deciding before knowing the difference between Elm and data-orientied. (Which I still don't) :)

[hecrj]

I am suggesting presenting the contrasts more explicitly could be useful to newcomers who need help deciding before knowing the difference between Elm and data-orientied.

I agree. However, I think both druid and iced (and most Rust GUI libraries) are currently in an exploration stage. We are basically trying to figure out what can and cannot work. This makes it hard to present contrasts: the ecosystem is constantly evolving and shifting.

Moreover, I don't think I am familiar enough with druid's internals to talk about it. For instance, I don't know how they plan to tackle dynamic layouts exactly.

In any case, I plan to build some bridges for collaboration soon!

[Matthias-Fauconneau]

Maybe expand on https://raphlinus.github.io/ui/druid/2019/11/22/reactive-ui.html explaining how iced currently fits in that framework ?