React-window: Question: What `will-change` is used for?

[oriSomething]

I see in https://github.com/bvaughn/react-window/blob/master/src/createListComponent.js#L276 that you're using will-change: transform. But from inspecting the demos it doesn't seems that transform is used anywhere

So, what will-change is used for?

[PascalSenn]

if you use will-change you force the element onto a new composition layer. It could be that this is used for performance optimization.

[bvaughn]

Yup, this is a performance optimization. You can learn more about it here: https://developer.mozilla.org/en-US/docs/Web/CSS/will-change

[MarkFalconbridge]

I may be wrong but I'm not convinced that will-change: transform is needed or adding any benefit here - in fact in my case it's causing a problem as it changes the ancestor element used for fixed elements. MDN states that a custom ident value means "Indicates that the author expects to animate or change the property with the given name on the element in the near future." In this case setting will-change: transform means that we expect to change the transform style of the element but that never actually happens. Further examples of how will-change can be used are given here - https://tympanus.net/codrops/css_reference/will-change/ including one where a transform is applied.

[bvaughn]

Admittedly it's been a long time since I added this style to react-virtualized. When I created this library, I kind of just copied it over without much thought. Looking back in my notes when I added the style:

Without this property, Chrome repaints the entire Grid any time a new row or column is added.
Firefox only repaints the new row or column (regardless of this property).
Safari and IE don't support the property at all.

Looking at the MDN docs again, maybe a value of will-change: contents; would make more sense to begin with? Or maybe the property is not really that helpful given that this is a windowing library and I'm actively managing element positions and rendering.

I don't have a lot of time right this moment to do any performance profiling to compare with and without this property. Would you be interested in lending a hand on this @MarkFalconbridge? I'd like to be confident before removing this style that it won't cause a perf regression.

[MarkFalconbridge]

I'm a little busy myself at the moment but I might be able to get to investigate performance profiling in a couple of weeks or so.

[bvaughn]

Sounds good. Let me know if you get around to it.

On Tue, May 21, 2019, 12:25 AM MarkFalconbridge [e-mail]
wrote:

I'm a little busy myself at the moment but I might be able to get to
investigate performance profiling in a couple of weeks or so.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/bvaughn/react-window/issues/47?email_source=notifications&email_token=AAAHHHJKXHO6BIM2GPHZF7DPWOPVFA5CNFSM4FRTAYV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODV276UA#issuecomment-494272336,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAHHHOYZFHYOJBJXM7AQN3PWOPVFANCNFSM4FRTAYVQ
.

[brunolemos]

If someone starts investigating this, please also experiment setting top or left instead of transform.

[SRachamim]

I suggest to reopen this issue. It adds little value and breaks fixed positions. Consider finding an alternative optimisation or not to optimise it at all.

This seems to me more like a hack than a legitimate optimisation, because will-change _actually influence the visual appearance of elements_.

[Hainesy]

This property affects z-index of absolutely-positioned child components, and means I cannot display an item as an inline-modal. Can will-change be optionally removed?

[oriSomething]

@Hainesy Hey, first of all, I think you better open a new issue, because usually closed issues are ignored by busy maintainers.
Second, You can work around it with creating modal with using a portal, and I actually think it's always a better solution, because there are many CSS properties that change z-index behavior, such as opacity and transform

[Hainesy]

@oriSomething Yes but if I use a Portal I lose the benefit of being able to fill the width of the parent container using left: 0, right: 0. I will have to use JavaScript to detect the width, but yes it's feasible.

[SRachamim]

You can work around it with creating modal with using a portal, and I actually think it's always a better solution

I'm not sure that portal is always a better solution. The other way around - you want to avoid portal as long as you can, and defaulting to it only when it's necessary (as when you want to use the inert attribute). portal requires external context, and have many potential issues. I discourage the use of it in our team. A dialog component is possibly the only use-case I can think of right now that actually makes sense to use portal. I'm sure that once you'll ignore the portal option, you'll find many simpler solution to your problems. Also, sometimes you even can't use portal (as when you need the CSS context of the parent).

react-window should do its domain effect: creating a virtual scrolling behaviour. Every other effect is a side-effect that the user (the developers in our case) won't expect. It should do it in the most efficient way, as long as it has no surprsing side-effects. i.e.: it shouldn't do it using techniques such as will-change that has side-effects to its children/parents/siblings.

[Romex91]

Without will-change, the scroll freezes until every item is rendered.
You won't see this on a modern CPU.

Reproduction steps on Chrome Windows:

1) Go Here
2) Ctrl+Shift+I
3) Performance->Cature Settings->CPU throttling->6x
4) Ctrl+Shift + C
5) Click the grid
6) Scroll the grid
7) Disable will-change style in Element->Styles
8) Scroll the grid again

What's wrong:

At step 8. scrolling gets laggy.

Why bother?

The problem becomes noticeable when you have heavier items.

What about other _will-change_ values?

@brunolemos FYI
top and left produce the same effect as transform
other will-change values have no effect