On Tue, 22 Sep 2020 09:14:31 GMT, yosbits 
<github.com+7517141+yos...@openjdk.org> wrote:

>> yosbits has refreshed the contents of this pull request, and previous 
>> commits have been removed. The incremental views will show differences 
>> compared to the previous content of the PR.
>
> I commented.

I've run SelectListView and SelectTableView tests and both run fine. As for the 
SelectTableView test, with 700_000 rows, when there is no selection, pressing 
SelectToEnd takes around 3.1 seconds, as expected. However, if there is one 
single row selected, after pressing SelectToEnd, the selection doesn't 
complete, and I have to abort and quit the app. 

Instead of:
tableView.getSelectionModel().selectRange(tableView.getSelectionModel().getFocusedIndex(),
 tableView.getItems().size());
this:
int focusedIndex = tableView.getSelectionModel().getFocusedIndex();
tableView.getSelectionModel().clearSelection();
tableView.getSelectionModel().selectRange(focusedIndex, 
tableView.getItems().size());
seems to work and times are again around 3 seconds or less.

Maybe you can check why that is happening?
 
And about the test discussion above, I understand that running the included 
tests as part of the automated test wouldn't make much sense (as these can take 
too long). However, maybe these could be added as unit tests with a reduced 
number of item/rows. Instead of measuring performance (selection times would 
depend on each machine), I'd say you could simply verify that selection works 
as expected.

While most of the changes are just about caching `size()`, the new 
implementation of `MultipleSelectionModelBase::indexOf` adds some new code that 
should be tested, as part of the unit tests, again not for performance, but to 
assert it returns the expected values.

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

PR: https://git.openjdk.java.net/jfx/pull/127

Reply via email to