-
Bug
-
Resolution: Unresolved
-
P3
-
jfx25
BorderPane has suffered a small regression after the height compute functions in Region (computeChildMinAreaHeight etc) were enhanced with a separate fillWidth boolean, to be used in cases where the child has a content bias.
The width is used in height calculations when the control contained is biased, allowing the control to react to the available width to return a suitable height. However, when the fill flag is false, this information is not used and instead a generic preferred width is used to calculate the height. This will not be able to produce good results as no information on the BorderPane's current size is used in the calculation...
This situation came to be because:
1. The old variants of Region's compute functions would always use the width for the bias calculations (as if fillWidth was true)
2. The updated code calls these with `false`, so it is no longer using the width.
3. The reason `false` was picked is that the counterpart calculations in BorderPane for **width** are passing `false` (and so the width calculations don't allow the actual available height to be used for biased calculations). This is likely a bug, and it is easy to prove this results in sub-optimal results.
This seemingly correct change significantly changes the height calculation of a BorderPane when a biased control is used, causing far more height to be allocated than needed as the calculation is now not based on the width available (which fillWidth controls) but on the preferred width the biased control returns. When the preferred width instead of the available width is used to subsequently calculate the height, the control does not adapt at all as this calculation route does not take any actual metrics of the BorderPane into account.
There are two paths we can take when fixing this bug:
1. Just fix the regression only, which means fixing the height calculation to work as before, and leave the width calculations (which are also not correct) alone to avoid disturbing these.
2. Fix the calculations for both width and height and take the actual height/widths into account (which seems to be the more correct way to deal with biased controls).
The width is used in height calculations when the control contained is biased, allowing the control to react to the available width to return a suitable height. However, when the fill flag is false, this information is not used and instead a generic preferred width is used to calculate the height. This will not be able to produce good results as no information on the BorderPane's current size is used in the calculation...
This situation came to be because:
1. The old variants of Region's compute functions would always use the width for the bias calculations (as if fillWidth was true)
2. The updated code calls these with `false`, so it is no longer using the width.
3. The reason `false` was picked is that the counterpart calculations in BorderPane for **width** are passing `false` (and so the width calculations don't allow the actual available height to be used for biased calculations). This is likely a bug, and it is easy to prove this results in sub-optimal results.
This seemingly correct change significantly changes the height calculation of a BorderPane when a biased control is used, causing far more height to be allocated than needed as the calculation is now not based on the width available (which fillWidth controls) but on the preferred width the biased control returns. When the preferred width instead of the available width is used to subsequently calculate the height, the control does not adapt at all as this calculation route does not take any actual metrics of the BorderPane into account.
There are two paths we can take when fixing this bug:
1. Just fix the regression only, which means fixing the height calculation to work as before, and leave the width calculations (which are also not correct) alone to avoid disturbing these.
2. Fix the calculations for both width and height and take the actual height/widths into account (which seems to be the more correct way to deal with biased controls).
- caused by
-
JDK-8350149 VBox ignores bias of child controls when fillWidth is set to false
-
- Resolved
-
- links to
-
Review(master) openjdk/jfx/1850