[DataGrid] Add will-change to CSS to improve performance in chrome full screen mode

[kertal]

Summary

Significant improvement of performance issues encountered in #3705. Screens taken using Chrome 83, MacBook Pro 15'' 2019 on a retina screen, rendering 100 rows.

Before:

After:

Important: pls test on a retina/high resolution monitor, there the lag is significant, and also the improvement

Checklist

- [ ] Check against all themes for compatibility in both light and dark modes
- [ ] Checked in mobile

• Checked in IE11 and Firefox - Note: IE11 doesn't know this CSS prop
  - [ ] Props have proper autodocs
  - [ ] Added documentation
  - [ ] Checked Code Sandbox works for the any docs examples
  - [ ] Added or updated jest tests
  - [ ] Checked for breaking changes and labeled appropriately
  - [ ] Checked for accessibility including keyboard-only and screenreader modes
• A changelog entry exists and is marked appropriately

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_3726/

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_3726/

[sulemanof]

I still think that the most desirable thing to optimize the data grid performance is virtualized scrolling. I bet if we apply it to the data grid, we'll get rid of such a hover problem, therefore the will-change will be unnecessary.
As MDN says, the will-change property should be used as the last resort, if there is no other optimization to apply.
So I would say the first-point task to apply is the usage of virtual scroll. If it doesn't help, the will-change will be used finally. IMHO

[kertal]

I still think that the most desirable thing to optimize the data grid performance is virtualized scrolling. I bet if we apply it to the data grid, we'll get rid of such a hover problem, therefore the will-change will be unnecessary.
As MDN says, the will-change property should be used as the last resort, if there is no other optimization to apply.
So I would say the first-point task to apply is the usage of virtual scroll. If it doesn't help, the will-change will be used finally. IMHO

I do agree, that virtualize scrolling should be the best solution, but the performance lag in Chrome on a retina screen justifies a in between solution IMO. I've adapted the CSS to apply will-change only on the transforms of the row.

[cchaos]

Hmm, reading through the spec, it seems that adding this directly to the stylesheet is not optimal. That, instead, the addition of this property should be handled via JS in anticipation of the change, not a blanket change. (See first example in the spec link).

[kertal]

Hmm, reading through the spec, it seems that adding this directly to the stylesheet is not optimal. That, instead, the addition of this property should be handled via JS in anticipation of the change, not a blanket change. (See first example in the spec link).

ok, agreed, will implement the JS approach

[kertal]

Hmm, reading through the spec, it seems that adding this directly to the stylesheet is not optimal. That, instead, the addition of this property should be handled via JS in anticipation of the change, not a blanket change. (See first example in the spec link).

I've tried to add the property directly but in this case it doesn't help, that was the draft

I think will-change needs to be added before the operation starts, but in this case, changing the background color on hover was already started by onMouseEnter. don't think there's a good solution to solve this, so it might be wiser to use the CSS way or to close this PR, it should be fixed by virtualization.

[cchaos]

Thanks for looking into that solution. Honestly, I'd rather just wait for virtualization rather than throw in a rule that could be more detrimental to the overall browser performance when DataGrid's don't exist.

[cchaos]

Actually, I will walk back my previous statement after reviewing your before and after screenshots again. There is quite an improvement being made. Let's go ahead and get this merged but, @chandlerprall can you be sure to test your virtualization effort without this?

The PR will need to be rebased with master to get the lastest changes to the changelog.

[kertal]

thx @cchaos, so I can also finish #3668 which made the performance worse in this case. had to force push, because rebase messed up the GitHub commit history, and no I wanted to adapt the Changelog, but the linter complains because of 293 errors, that seem to be unrelated to my 1 line of Changelog add-on 😄. how should I fix this?

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_3726/

[kertal]

ok, seemed to be a eslint cache issue that has been resolved locally be upgrading node. I could commit the changelog entry

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_3726/