...and separate it from minimum opposite size-for-size computation.
Previously, the two were intertwined.
In broad terms, gtk_box_layout_compute_opposite_size_for_size () gathers
minimum and natural size requests of the child widgets *along* the box's
own orientation, and then uses gtk_distribute_natural_allocation () to
distribute the available size (the size being measured for, minus any
spacing) between them. This mirrors what gtk_box_layout_allocate () does
to distribute the allocated size. Once the available space along the
box's orientation has been distributed and a size assigned to each
child, gtk_box_layout_compute_opposite_size_for_size () measures
children in the opposite orientation for those sizes assigned to them,
and then does the usual aggregation (namely, MAX + baseline handling) on
the resulting list of size requests.
In commit 76c4673944 "boxlayout: Fix
broken min-size-for-opposite-size", it has been discovered that simply
distributing available size based on the size requests in that one
orientation -- the way that gtk_distribute_natural_allocation () does it
-- leads to reporting incorrect minimum opposite size. This is not an
issue during allocation, since there, the size requests of the children
already account for the available space in the other orientation. To fix
this for the measurement logic, a new code path was introduced that uses
binary searching to reliably discover the minimum size in the other
orientation.
The minimum size found by the binary search, however, was not getting
directly used to report the box' minimum size. Instead, the size
requests of child widgets would get measured based on the discovered
minimum size (just as they are during allocation), and then fed into the
generic gtk_distribute_natural_allocation-based logic described above.
Since minimum size is (assumed to be) monotonic, and both distributing
extra space towards natural sizes and applying expand flags could only
increase the size of the children along the box's own orientation, the
minimum size in the opposite orientation that got computed should match
the one that was found during binary searching.
But there are still issues with this. For one thing, the implementation
had a bug, in that it wouldn't actually re-measure size requests based
on the final minimum size discovered during binary searching; instead,
it would use the values left in sizes[i].minimum_size and
sizes[i].natural_size by distribute_remaining_size (). Those were indeed
often the measurements for the found minimum size (in case the last
iteration of the binary search accepted the candidate size). In case the
last iteration took the other branch, ruling out the candidate size,
those leftover measurements would simply be incorrect, and the box would
likely end up reporting minimum opposite size being smaller by 1px
compared to the correct value. This is a simple bug in the code and not
a fundamental issue with the approach.
A more serious issue is the following: the distribution of child sizes
along the box's own orientation that achieves minimum size in the
opposite orientation might be quite different from the one that would be
considered "natural", as in describing the layout that produces the
natural size in the opposite orientation. For a specific example,
cosider a box containing a wrappable GtkLabel and a GtkPicture. Since
the picture's minimum size is 0 (assuming can-shrink is not unset), the
layout that achieves minimum size in the opposite orientation is the one
that gives the label as much size along the box's own orientation as the
label is able to make use of, only assigning the remaining part (if any)
to the picture. Moreover, the actual size assigned to the picture may be
even smaller than the remaining part, since the picture's natural size
request will be measured based on that (small) minimum size in the
opposite orientation, and the picture expanded from its minimum size of
0 up to that size. Measuring the natural size in the opposite
orientation will then likely produce the same value as the minimum size
again. This will happen even if the available size in the box's own
orientation was enough to fit the label and the picture at their natural
sizes, which would then allow them to ask for their full natural sizes
in the opposite orientation. The only reason for this is that for
measuring the natural size, we picked a size distribution that was
optimized for producing the smallest possible minimum size, and one has
little to do with the other.
Similarly, consider the case of a horizontal box containing a label that
has its natural width limited by setting max-width-chars. Such a label
is able to make use of more horizontal space than its natural width to
reduce its height request, when that is required. By computing the
minimum height possible and considering label's minimum and natural
widths for that height as the basis for the following distribution of
available width, we'll force the label to take up more width that its
natural size even though we're not actually vertically constrained,
which will then result in it asking for less height than its normal
natural height.
The reftests added in this commit demonstrate the issues in the cases
described above.
Moreover: there is an optimization that we'd like to implement, namely
it should be possible to avoid the binary search in case of a single
inconstant-size child, and instead ask the child about its minimum size
directly. However, in order to fit this approach into the existing
gtk_distribute_natural_allocation-based logic, we have to rely much more
on the child widget reporting consistent width-for-height and height-
for-width measurements. An initial attempt to implement this
optimization, https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6569,
ran into many cases where this just wasn't so in practice, which broke a
number of layouts, and while specific individual cases of inconsistent
measurements are being fixed, merging this optimization is just not
feasible. Separating computation of minimum and natural sizes allows the
direct measurement of a single child optimization to only affect the
computation of minimum size, without either breaking natural size or
running into contradictory measurements.
So, this patch does just that.
distribute_remaining_size () no longer fills sizes[i].minimum_size and
sizes[i].natural_size; it now only calculates the minimum size, and that
calculated size is used directly for the reported minimum size of the
box. gtk_distribute_natural_allocation-based logic is only used for
measuring the natural size in the opposite orientation, and the minimum
and natural sizes passed to it are just overall minimum and natural
sizes. (The produced layout is still kind of being used for measuring
baselines, but those are hopefully only used with constant-size
children, whose baseline and size doesn't depend on the distribution.)
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
Sergey Bugaev