Iced: Layout backtracking

[daxpedda]

Currently Row/Column/Grid are trying to distribute their elements while respecting the maximum size of the window.
The issue is the algorithm calculates the size of each element and tries to fit that in, but if the total size of all elements in one dimension is bigger then the window, it will not try to make the other elements smaller to fit everything, cutting off elements even though it could easily wrap text in earlier elements for example.

A solution is basically to introduce some correcting code that tries to reduce the dimensions of the elements as much as possible when it sees that it hit that limit.

I plan to do that PR myself, just waiting for #189.

[hecrj]

This will be very hard to do right and will affect layout performance considerably. It also makes layout less predictable, as you never know the amount of space elements will take.

We can explore alternatives to the current layout strategies, but I would do that in completely separate widgets. The current ones are meant to be simple, explicit, and fast.

[daxpedda]

This will be very hard to do right and will affect layout performance considerably.

I don't think this should be an issue, my current experiments are quite cheap, I'm basically checking limits only once at the end and then adjust them with some basic math and min/max.

It also makes layout less predictable, as you never know how much space will elements take.

I don't think it's very predictable that things are just cut off when they are too long to fit the screen.
So I think this will be an improvement, we can also make it opt-in, which could also "solve" the performance issue.
We could also discuss making the window scroll when something doesn't fit, but I guess thats even more off-topic.

We can explore alternatives to the current layout strategies, but I would do that in completely separate widgets.

Any thought on which ones specifically?

[hecrj]

I don't think this should be an issue, my current experiments are quite cheap, I'm basically checking limits only once at the end and then adjust them with some basic math and min/max.

How do you do this exactly? If you decide to reduce the bounds of a previous element, you will need to measure it again as contents may be wrapping differently, affecting its width or height. That is expensive.

In the end, we will be trying to reimplement Flexbox and end up with something similar to stretch, which we used in the past and performance was much worse than now.

I don't think it's very predictable that things are just cut off when they are too long to fit the screen.

It's predictable in the sense that layout always will behave the same in terms of logic and performance. If you want things to be responsive and fit nicely, you should be using Fill or FillPortion.

I agree this is something that needs more polishing, but it's hardly our main priority right now.

Any thought on which ones specifically?

New ones.

[daxpedda]

How do you do this exactly? If you decide to reduce the bounds of a previous element, you will need to measure it again as contents may be wrapping differently, affecting its width or height. That is expensive.

Yes, that is totally true, I totally missed the remeasuring part 😕. Me derp.
Potentially this would only "double" the cost, lol.

I agree this is something that needs more polishing, but it's hardly our main priority right now.

That sounds reasonable. I was already experimenting on grid, but I can totally agree that this isn't the priority right now.

[hecrj]

Potentially this would only "double" the cost, lol.

Not really, because widgets are recursive. You can have many levels of nested rows and columns. If they all backtrack and try to fit elements smartly, then the cost will add up quickly (i.e. remeasuring from a top-level column could trigger a lot of measurements in its children and so on).

That sounds reasonable. I was already experimenting on grid, but I can totally agree that this isn't the priority right now.

Don't get me wrong, I would love for folks to explore new layout strategies! But I think it's something we need to discuss thoroughly, measure performance, and consider tradeoffs. We are not ready to write code for this yet.