| SelectionLayer and SelectionModel: Performance troubles [message #1267855] |
Sun, 09 March 2014 17:46  |
|
Hi,
We recently had some severe performance problems when a large amount of cells are selected (> 10.000 selected cells in a table with 1.000 lines and 10 columns). I had a quick look at the SelectionModel and discovered that the selected cells are kept in a list. So basically the determination whether a given cell is selected is extremely expensive. In the worst case all elements have to be inspected to determine that a given cell is or is not selected.
I came up with the idea to write a new SelectionModel that tracks the selections in a map. Lookup would be cheaper and the performance would not be influenced by the number of selected cells. However I stumbled across a major problem while doing this:
The SelectionLayer DIRECTLY modifies the last rectangle added to the SelectionModel.
Let me explain this a little bit more detailed with the API calls that are made against the model when doing a selection. Given a table with a single row and two columns:
Cell 1 Cell 2
---------------------
| x=0,y=0 | x=1,y=0 |
---------------------
*) Select the first cell by clicking on it:
ISelectionModel#addSelection with a rectangle {0, 0, 1, 1} is called as expected.
*) Without releasing the mouse move the cursor to the next cell:
ISelectionModel#addSelection with a rectangle {0, 0, 2, 1} is called. This is a little bit surprising since I would expect to get only the new rectangle {1, 0, 1, 1} but that's OK.
BUG: The SelectionModel now has two entries (same instance): [Rectangle {0, 0, 2, 1} AND Rectangle {0, 0, 2, 1}]
*) Again without releasing the mouse move the cursor back to the first cell.
ISelectionModel#addSelection with a rectangle {0, 0, 1, 1} is called. Now this is really surprising since I would expect a call against ISelectionModel#clearSelection with the removed cell.
Bug: The SelectionModel now has three entries (all the same instance): [Rectangle {0, 0, 1, 1}, Rectangle {0, 0, 1, 1} AND Rectangle {0, 0, 1, 1}].
Basically nobody tells the model to remove the now non selected cell. This is only working as the SelectionModel directly modifies the rectangle that is stored in the list of the selection model. When the model would store a copy of the rectangle and not the same instance that is passed it would stop working. Is the observed behavior a bug or has this been implemented intentionally?
Just as information why we are doing this: We are calling ISelectionModel#getSelectedRowPositions to attach a label to each cell if at least one cell in the same row is selected. This causes severe performance troubles when a large amount of cells is selected. We could find a workaround for this single place but there are more calls against the selection layer... They would all benefit from a faster implementation that does less calculations for all the provided getters.
Any suggestions how to go on with my custom implementation?
Regards
Michael
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.02577 seconds
] 
Search
Help
Register
Login
Home
