Multi-cell selection of hundreds of cells takes ages to show up

[oleq]

📝 Provide a description of the improvement

1. Go to https://en.wikipedia.org/wiki/List_of_countries_and_dependencies_by_population.
2. Copy and paste the big countries table (243 rows in total).
3. Select some cell at the beginning of the table.
4. Scroll to the end (or near the end).
5. SHIFT+Click to create a huge selection across ~200 rows.

Expected: That's a lot of cells, I get it but the acceptable delay is 1s tops.

Actual: Around ~3s on a i7 MacBook. That's a lot.

Funny fact: De-selecting (e.g. clicking in a cell to create a collapsed selection) is lightning fast. So it's not about rendering but about calculating the selection and it should be simpler to improve.

It looks like the selection.setRanges() is the performance hog

because we pass billions of ranges there. Maybe instead of

<row>[<cell />][<cell />][<cell />][<cell />][<cell />]</row>

we could at least

<row>[<cell /><cell /><cell /><cell /><cell />]</row>

to limit the number of ranges passed to the engine?

@jodator @Reinmar

---

If you'd like to see this improvement implemented, add a 👍 reaction to this post.

[Reinmar]

The outline is a mess:

There's definitely something wrong on convertSelection() (the middle part):

But then we have rendering which isn't better because it causes hundreds of reflows:

[Reinmar]

I'd say that it nicely shows at least 3 or 4 issues and I don't expect one quick fix here. For instance, selecting multiple cells in one range like @oleq proposed will not fix the rendering which is per-cell.

[Reinmar]

As for the rendering part – my guess is that it may be a regression caused by the table selection overlay introduced recently.

[CKEditorBot]

There has been no activity on this issue for the past year. We've marked it as stale and will close it in 30 days. We understand it may still be relevant, so if you're interested in the solution, leave a comment or reaction under this issue.

[CKEditorBot]

We've closed your issue due to inactivity over the last year. We understand that the issue may still be relevant. If so, feel free to open a new one (and link this issue to it).