You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I don't think this issue can be produced with the current API, so this is an improvement instead of a bug for now.
It seems that stretch chooses the wrong bounding box for the Node. Text should shrink and have its own width, while filling horizontal space of its parent when possible. Maybe I am wrong, but I think that is the whole point of measure functions.
Additionally, when I implemented the Text widget, I noticed that stretch was calling the measure function provided in Node::with_measure way too many times. I was able to optimize this by using a RefCell to cache the first measurement, which seems to be the only one that matters. This last assumption could be wrong, but toggling this optimization seems to have no effect on the issue described above.
In any case, I think both things could be related. We should try to create a simple test in the stretch codebase reproducing the problem and open an issue/PR.
The text was updated successfully, but these errors were encountered:
If we stop the
Text
widget from filling the width of its parent by default and its parent aligns items usingAlign::Start
(the default),Text
just keeps growing horizontally with no limit:I don't think this issue can be produced with the current API, so this is an improvement instead of a bug for now.
It seems that
stretch
chooses the wrong bounding box for theNode
.Text
should shrink and have its own width, while filling horizontal space of its parent when possible. Maybe I am wrong, but I think that is the whole point of measure functions.Additionally, when I implemented the
Text
widget, I noticed thatstretch
was calling the measure function provided inNode::with_measure
way too many times. I was able to optimize this by using aRefCell
to cache the first measurement, which seems to be the only one that matters. This last assumption could be wrong, but toggling this optimization seems to have no effect on the issue described above.In any case, I think both things could be related. We should try to create a simple test in the
stretch
codebase reproducing the problem and open an issue/PR.The text was updated successfully, but these errors were encountered: