Best way to optimize performance for a virtualized spreadsheet/grid?

[MartinDawson]

So right now any cells that are not in the users viewport are moved to the new position and updated with the new text and styles with setAttrs and getAttrs as I asked in the other issue

This works well apart from when a user has tons of cells in the viewport at one time and starts scrolling. You can see in the gif that I get 10fps on scroll.

The big issue is that currently I cannot cache anything with .cache() before scrolling as the new cells need to be rendered in the correct places on scroll so konva has to recalculate all nodes onScroll I think.

Here's my thoughts on how to it (and how I think Google Sheets does it):

1. Pre-load the current viewport cells & disable scroll bars.
2. Use a web-worker to render all the other cells with konva as normal nodes.
3. Convert the entire canvas and out of viewport cells to an image using layer.toImage().
4. When the user scrolls move the image and hide the cells. When the user stops scrolling, show the cells and hide the image.

Is their any easier way to do this than the above that I might be missing?

There could be theoretically 100,000's of cells which is why I am thinking web worker in step 2.

Or maybe use off-screen canvas as well?

[lavrton]

@MartinDawson can you publish your performance stress test online? I can take a look.

Personally, I am not sure web worker is a good solution. I think it may complicate the app architecture too much.

[MartinDawson]

Thanks, I'll try and see what is going wrong then.

I also noticed that rowsNColumns has the same slow performance if you fill one cell in with lots of styles and copy/paste it to all the other cells it laggs. https://rowsncolumns.app/demo

One thing that really slows it down is having lots of borders on a cell, in your demo you used a stroke. However this can't be done in real app because a user could put only a left border or a right border. So up to 4 new lines have to be created for every cell depending on how many borders a user puts on a cell.

[MartinDawson]

@lavrton So I've created this demo which is yours but updated with the scrollbar. If you move the scrollbar up and down really fast it goes down to 15~ fps for 26 columns.

I'm just wondering though if you can see any further optimisation in the updated example? As 15fps is usable but not amazingly smooth.

Wheel scrolling is different because it only has to destroy/render a few rows at a time, if a user scrolls fast it has to destroy/render entire viewports every 16 ms.

https://jsbin.com/lapinusozu/16/edit?js,output

EDIT: I pruned my code down to the js example and got around the same speed I think the issue is just a lot of data needs to be re-rendered each scroll. Turns out using lodash throttle for scrolling reports a more than 10 fps drop compared to setTimeout but I think this is a google FPS issue cause the speed seems the same.

[MartinDawson]

It seems the demo has cell heights of 50, but we have cell heights of 25, this means half the cells in the viewport.

Google Sheets has cell heights of 25.

https://jsbin.com/lapinusozu/17/edit?js,output

You will get 10 fps on the above example...

[lavrton]

I got this version: https://jsbin.com/qozicepule/1/edit?js,output
With a bit of monkey patching for font measures (to use cache) it is faster. But even without it, the perf is good.

Moving a stage with many children elements is slow. So, stage and groups are static. Position is not changed. But content of groups is changing, so visually it looks like moving.

[MartinDawson]

@lavrton Ah thank you! Yes that will be what I was doing wrong was moving the entire cells parent group each time instead of simulating it. Even on 6x slowdown it's useable now on your demo. Awesome.