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 <rlich...@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
