On Sun, 2 Jul 2023 12:53:05 GMT, John Hendrikx <jhendr...@openjdk.org> wrote:
> My observation is that this algorithm seems unable to provide a proper user > resizing experience as it seems to discard important information it would > need to do so. please elaborate, or point to a specific problem. It is entirely possible that a better algorithm might exist, but it might be out of scope *at the moment*, as this is a follow-up for a specific issue. > The `ResizeHelper` is short-lived, and created/recreated many times during a > resize operation. I'm not even sure why it is being instantiated at all (it > literally is created and discarded in a single method). convenience - it does have some data, and it's easier to keep code along with the data. > The `SMALL_DELTA` constant that changes behavior on how large a "drag" was > registered is a red flag; this shouldn't matter. The sizes should always be > based on what they were initially (at the start of the drag), and where the > cursor is currently, regardless of what path the cursor took to get there > (ie. there should be no memory effects, the algorithm should only need the > initial sizes + current position). This is not my experience. Specifically, the difference in behavior between small changes (when the users resizes the columns slowly and we get small deltas of 1 pixel) and large changes (e.g. when initially resizing the table, or the user moves the mouse quickly) are significant. For example, I tried to use your SpaceDistributor from #1111 and it suffered from the same problem as bypassing the small delta path (by setting SMALL_DELTA=0) - when the user resizes the columns slowly, the same column gets the pixel and grows wider than the rest. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-1622127738
