RFR: 8311527: Region.snapInnerSpace*()

[John Hendrikx]

On Sat, 29 Jul 2023 00:12:45 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Introduces Region.snapInnerSpaceX/Y() methods for dealing with inner space (using Math.floor), see for instance [JDK-8299753](https://bugs.openjdk.org/browse/JDK-8299753), using existing methods Region.snapPortionX/Y().

Are you sure you'll be needing these methods for solving the table column resizing issues? For dealing with space, there are already the `snapSpace` methods, which do rounding.

The linked ticket does not really explain why these would be needed, just that they might be needed for a potential new algorithm that doesn't exist yet. The ticket also mentions that the table column resizing might need an algorithm that does multiple passes; I'm not sure if that's really needed -- it's tempting to write a column resizing algorithm by incrementally adjusting sizes during the resize, but that will lead to an accumulation of small errors eventually resulting in the mouse cursor no longer tracking the column edge being resized.  If the algorithm were rewritten to track the initial state of all columns, then apply a calculation that takes initial state + current drag location for as long as the drag is in progress, then it becomes much more predictable and testable, ie:

inputs:
   initial sizes: [10, 10, 10, 10]
   column being resized: 2
   start mouse location: 20
   current mouse location: 15

output (depending on the resize algorithm):
   sizes: [10, 5, 10, 15]

When the mouse is moved again, the calculation is again done from the initial inputs, discarding anything that was calculated in the first calculation:

inputs:
   initial sizes: [10, 10, 10, 10]
   column being resized: 2
   start mouse location: 20
   current mouse location: 25

output (depending on the resize algorithm):
   sizes: [10, 15, 10, 5]

This will avoid errors accumulating, and moving the cursor around will give the same result column sizes as long as the drag operation is ongoing.  Once the drag finishes, only then are the sizes finalized.

Having a small helper class that can be easily unit tested for the various resize options may be good.

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

PR Comment: https://git.openjdk.org/jfx/pull/1190#issuecomment-1709307950