On Mon, 19 Dec 2022 19:11:25 GMT, Andy Goryachev <ango...@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
