RFR: 8325154: resizeColumnToFitContent is slower than it needs to be
Robert Lichtenberger
rlichten at openjdk.org
Tue Feb 6 06:27:00 UTC 2024
On Mon, 5 Feb 2024 16:02:46 GMT, Andy Goryachev <angorya at openjdk.org> wrote:
> > , in order to "not break things" we would have to introduce an API to users to be able to control the number of rows they want to be taken into account.
>
> I think the UI "breaking itself" is much worse than us changing the (buggy) behavior. The user gains very little if the UI locks up for several seconds (or minutes) trying to size every row.
I don't agree. Our production application usually loads 200 rows and lets the user load as many more rows as they see fit. It also provides a "fit all columns" function which will fit all columns of the table.
Users are fine with a few seconds of blockage if they have loaded thousands of rows. But if the "fit all columns" function will no longer work, they will report a bug which I will not be able to fix, if JavaFX suddenly refuses to iterate over all the rows as it does now.
So maybe we should:
* Provide an API that let's the client specify how many rows should be taken into account
* Make resizeColumnToFitContent available for clients
>
> At the same time the user might simply double click on the header again (or better, just resize the offending column like they used to do since time immemorial) once a wide cell comes into view.
>
> Basically, I don't think the new API is required in this particular case; I think it's a bug and it should either size the visible rows or (visible + some margin). Of course, there is one more operation which guarantees a lock up with large models - sorting. There is no easy solution for sorting, and that's where we _might_ need new APIs. And it is a totally separate issue.
-------------
PR Comment: https://git.openjdk.org/jfx/pull/1358#issuecomment-1928861769
More information about the openjfx-dev
mailing list