4 ms·

I have spent way too much time building grid components at my company, and I've found that if you have (1) a lot of data, (2) a dense grid, and (3) a grid that

I have spent way too much time building grid components at my company, and I've found that if you have (1) a lot of data, (2) a dense grid, and (3) a grid that occupies most of the screen, THEN the only way to get 30+fps is to use canvas and do all the layout and drawing logic yourself.

miralabs 10y ago
canvas would be a pain to have automated test. https://github.com/openfin/fin-hypergrid/issues/540 https://github.com/openfin/fin-hypergrid/issues/540
- wdfx 10y ago
  even with sikulix ?
- djfumberger 10y ago
  Maybe that's the compromise for a good user experience?
toomim 10y ago
Or you can do what google sheets does: only draw N cells at any time, and just change their contents depending on where you are scrolled to.
- cloverich 10y ago
  This is "virtualized" views; other comments in this thread link to some relevant projects!
- georgewfraser 10y ago
  Google sheets uses canvas. The strategy you describe is orthoganal to canvas versus DOM.
  - ic4l 10y ago
    I had to verify this... I cant believe it, they doing all the rendering logic for all the cells in canvas. They are not rendering simple cells either, sheets has may features :O. Testing would be the easy part, in some cases it would be easier than DOM because you can do image diffs... The harder part is BUILDING IT.
    - chrishere 10y ago
      They applied some kind of mixed model in which the entire effort connected with rendering the body of the grid (cells) is being drawn in canvas and the rest of it, including headers, selection and editors, are rendered in a regular way. There is no doubt that Google Sheets keeps almost all of its logic on the back-end side.
TheAceOfHearts 10y ago
Have you tried out react-virtualized [0]? The author has invested a ton of time tweaking things left and right in order to get optimal performance. It's by far the best virtualized grid in JS that I've had the pleasure of using. In addition to that, the React Fiber rewrite should eventually introduce a few new APIs which, as I understand it, should enable further performance improvements. If you scroll really fast it'll flicker white and rendering will lag behind a bit, but it won't cause any jank, so the interface remains at 60FPS. It exposes a good number of params which you can tweak to suit most needs. Personally, I think it's not a big deal, as long as the UI runs smoothly. It takes a few extra ms for the view to catch up if I scroll really fast... But I've had similar the same experience with Apple's Numbers and with browsers trying to render huge HTML tables and it hasn't bothered me. I've gone back on forth on this topic quite a bit. I used to be a strong believer you should virtualize everything. But then you've broken in-browser search, and you find yourself having to write and support even more code. Using canvas? Say goodbye to accessibility. Now, I'm not saying this is the case for your use-case, but I think that in some cases it's worth seriously reconsidering the design and just going with a simple table that leverages built-in browser functionality and traditional pagination. If you have so much data that you struggle to load and display it with JS, it may be a good idea to take a step back and explore alternative strategies for presenting the data to your users. As an extreme example, a 1 million by 1 million table would probably contain too much data for any consumer to really make sense of it. I only say this because I had a couple experiences where having heard that might've helped keep things simpler. I'll still happily reach for react-virtualized when I find a situation that merits its use. [0] https://bvaughn.github.io/react-virtualized/#/components/Grid https://bvaughn.github.io/react-virtualized/#/components/Gri...

miralabs 10y ago

canvas would be a pain to have automated test. https://github.com/openfin/fin-hypergrid/issues/540 https://github.com/openfin/fin-hypergrid/issues/540

wdfx 10y ago
even with sikulix ?
djfumberger 10y ago
Maybe that's the compromise for a good user experience?

toomim 10y ago

Or you can do what google sheets does: only draw N cells at any time, and just change their contents depending on where you are scrolled to.

cloverich 10y ago
This is "virtualized" views; other comments in this thread link to some relevant projects!
georgewfraser 10y ago
Google sheets uses canvas. The strategy you describe is orthoganal to canvas versus DOM.
- ic4l 10y ago
  I had to verify this... I cant believe it, they doing all the rendering logic for all the cells in canvas. They are not rendering simple cells either, sheets has may features :O. Testing would be the easy part, in some cases it would be easier than DOM because you can do image diffs... The harder part is BUILDING IT.
  - chrishere 10y ago
    They applied some kind of mixed model in which the entire effort connected with rendering the body of the grid (cells) is being drawn in canvas and the rest of it, including headers, selection and editors, are rendered in a regular way. There is no doubt that Google Sheets keeps almost all of its logic on the back-end side.

TheAceOfHearts 10y ago

Have you tried out react-virtualized [0]? The author has invested a ton of time tweaking things left and right in order to get optimal performance. It's by far the best virtualized grid in JS that I've had the pleasure of using. In addition to that, the React Fiber rewrite should eventually introduce a few new APIs which, as I understand it, should enable further performance improvements. If you scroll really fast it'll flicker white and rendering will lag behind a bit, but it won't cause any jank, so the interface remains at 60FPS. It exposes a good number of params which you can tweak to suit most needs. Personally, I think it's not a big deal, as long as the UI runs smoothly. It takes a few extra ms for the view to catch up if I scroll really fast... But I've had similar the same experience with Apple's Numbers and with browsers trying to render huge HTML tables and it hasn't bothered me. I've gone back on forth on this topic quite a bit. I used to be a strong believer you should virtualize everything. But then you've broken in-browser search, and you find yourself having to write and support even more code. Using canvas? Say goodbye to accessibility. Now, I'm not saying this is the case for your use-case, but I think that in some cases it's worth seriously reconsidering the design and just going with a simple table that leverages built-in browser functionality and traditional pagination. If you have so much data that you struggle to load and display it with JS, it may be a good idea to take a step back and explore alternative strategies for presenting the data to your users. As an extreme example, a 1 million by 1 million table would probably contain too much data for any consumer to really make sense of it. I only say this because I had a couple experiences where having heard that might've helped keep things simpler. I'll still happily reach for react-virtualized when I find a situation that merits its use. [0] https://bvaughn.github.io/react-virtualized/#/components/Grid https://bvaughn.github.io/react-virtualized/#/components/Gri...