RFR: 8325154: resizeColumnToFitContent is slower than it needs to be

[John Hendrikx]

Hi, just wanted to add my 2 cents,

In my opinion, no operation in List/Table/TreeTable should be doing such 
measurements on all rows or columns (where cells need to be loaded, CSS 
aplied, etc) -- it just won't scale.  In my application many of my lists 
contain images, and pre-loading all of these to do measurements is just 
not possible (luckily I can use fixed size cells).

So, I think that by default it should work on *visible* cells only, and 
use estimates for the rest of the cells.  This is how browsers deal with 
huge tables (they for example won't preload every image in a table to 
"measure" the size of cells).  The estimates can be adjusted as more 
cells have become visible (or nothing happens at all if the user is not 
interacting with the control).

As I think there are wildly different requirements for each view, I 
think it may be a good idea to implement size estimations using a 
Strategy pattern (like the FocusModel and SelectionModel), where the 
default strategy is based on visible cells, and can be replaced with 
other strategies that measure or estimate differently.  Already there 
are implementations and ideas for:

- Fixed size
- Visible cells only + estimates
- All cells
- First 15, bottom 15
- First 1000 rows

I don't think there will be a one size fits all, so I think 
externalizing this problem and having the user choose or even implement 
their own would be a more tenable solution.  I feel this problem has 
gone back and forth several times now during the life time of TableView :)

--John


On 05/02/2024 10:48, Marius Hanl wrote:
> On Mon, 5 Feb 2024 09:31:37 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:
>
>> A side comment: the default implementation of resizeColumnToFitContent() is to iterate over all the rows, and I think this is not right. The UI locks up if the table has, let's say, 10,000,000 rows. I think in this case it should instead pick a reasonable limited range (maybe a max 1000 rows or so) of rows based on what's currently visible, so as not to lock up the UI. This might be a separate improvement.
> I agree as well. This is on my todo list for quite a while.
> The default auto size is done with 30 rows. If you double click the edge of the header, it will take ALL rows, which can be very slow.
> So +1 here. Also another idea I had is to take 15 top rows and 15 bttom rows into account. In case the table is sorted.
> We can disuss this more in a seperate issue.
>
> I will review this PR soon as well.
>
> -------------
>
> PR Comment: https://git.openjdk.org/jfx/pull/1358#issuecomment-1926583385