[REVIEW REQUEST] Improvements to TableView sorting

[John Hendrikx]

On 19/02/2013 23:41, Knut Arne Vedaa wrote:
> John Hendrikx wrote:
>> - Transforming a select range of 0-500000 to many smaller select ranges
>> when a resort occurs
>
> Can you actually get a range out of SelectionModel, and not just a 
> series of indices? It doesn't seem so from the API as far as I can tell.
No, but the point is that the selection must be maintained after a 
resort and if this involves transforming the SelectionModel (setting 
different bits in a bitmap, or changing ranges) then that's quite an 
expensive operation.  A selection model that is sort order independent 
would not need any transformation.

>> - Depending on the backing list, many random deletes in a huge List will
>> be costly (ArrayList won't cut it, any Events being triggered on
>> modification of the list will likely also introduce a huge bottleneck).
>> Note that the use case specifically causes these deletes to be random!
>> It's not possible to do it in a single remove event.
>
> Can't you do it in a single operation if you use List#removeAll?
No, if you select the top half of the items in a list sorted by Last 
Name, then resort the list by First Name, the selection will no longer 
be a single range.  If you decide to delete them at that point, you'll 
have to do many small deletes.
>
>> - Resorting after every list change
>
> It shouldn't be necessary for SortedList to re-sort after a delete, as 
> the order of the remaining items stays the same.
Correct, so this must be avoided (Swing didn't).  Note that the 
selection model in Swing was index based, so it still needed adjustment 
after every delete...
>
>
> Knut Arne
>