RFR: 8293119: Additional constrained resize policies for Tree/TableView [v24]

[Kevin Rushforth]

On Mon, 19 Dec 2022 19:11:25 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810).
>> 
>> We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically:
>> 
>> - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class
>> - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS
>> - add corresponding public static constants to Tree/TableView
>> - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss)
>> - add getContentWidth() and setColumnWidth(TableColumnBase<S,?> col, double width) methods to ResizeFeatureBase
>> - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase
>> - update javadoc
>> 
>> 
>> Notes
>> 
>> 1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value.
>> 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293119: review comments

The problem I mentioned earlier about constrained resizing not working well on Windows HiDPI is still there; it is not preexisting behavior, so will need to be addressed by this PR. I did a little more testing, and can better characterize the problem.

To reproduce this, run the test program as follows on Windows with a screen scale of 1.25:

1. Select "Data" -> "pref only"
2. Select "Policy" -> "AUTO_RESIZE_FLEX_LAST_COLUMN"
3. Drag the divider between "C2" and "C3" _very slowly_ to the right
4. BUG: most of the time there is no movement at all; occasionally column 2 will resize a bit larger and column 4 will resize a bit smaller

With a screen scale of 1 it seems to work as expected.

I think that the code that does some of the computation in integer arithmetic is interacting with the default "snap to pixel" behavior when the screen scale is > 1. The misbehavior is most noticeable when dragging the divider between cells very slowly. I suspect that you need to rethink using integer arithmetic. It doesn't seem like the right thing to do anyway (at least not without a good explanation of why it is needed), and I believe is the cause of this problem.

If the reason for using integers is to align with snap-to-pixel behavior, then you should instead use doubles and use the snap-to-pixel utility methods (in `Region`).

modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ResizeHelper.java line 62:

> 60:         min = new int[count];
> 61:         pref = new int[count];
> 62:         max = new int[count];

Using integer arithmetic may not be the right thing to do here.

-------------

PR: https://git.openjdk.org/jfx/pull/897