Remove auto `will-change`

[mattgperry]

Fixes https://github.com/framer/motion/issues/2816 Fixes https://github.com/framer/motion/issues/2763

Auto will-change was an attempt at semi-intelligently applying will-change for the right values when animations trigger.

Due to various rendering issues (the above tickets, https://github.com/framer/motion/pull/2818#issuecomment-2392690623 and things we've seen in Framer) I think the safer thing to do is to remove this and leave it to users.

This PR removes auto will-change but allows users to opt-in as before via useWillChange.

[robmeede]

Any chance this PR will be part of a release soon?

[mattgperry]

@robmeede Probably today or tomorrow but you can already override with style={{ willChange: "auto" }}

[ynamite]

@mattgperry this fix doesn't work with useAnimate (or rather animate) though, right? Is there a similar fix? Right now I'm setting will-change manually after a setTimeout. Fugly, but it works :)

Out of curiosity, how big of a performance impact does will-change have or what was the rationale behind adding auto will-change?

[mattgperry]

@ynamite That's right actually, you'd either have to pass it through as an animated value or change the element to a motion component. But yeah this will be fixed in the next release.

Interested in what was breaking for you with it?

Ideally this would be something I could take off people's plates. As the performance benefit can differ between Safari/Chrome/devices. And making too many layers can be detrimental.

I'm removing it now actually because users are reporting various problems with it, but then manually adding it back in Framer because we're seeing performance improvements, especially during scroll, when its added.

Personally I don't believe the measured performance benefits are that great but the perception was that framer.com was smoother with it and sometimes that's more important. But my feeling now is I can't automate it in a way that's useful for a broad range of people, hence this PR.

[ynamite]

Ah I see, thanks. I believe I tried solving it as you suggest, but couldn't get it to work. But maybe I'd done something wrong.

And thanks also for the explanation. In my case I'm handling route transitions with Framer Motion. Some pages have modals (triggered after a click on a button) and these modals have position fixed. It's not a problem when the whole view is transitioned, but if it's only certain components of a view, the modals would then be positioned relative to the parent that is being transitioned (stacking context) as long as will-change is set to something other than auto.

I actually quite like the idea of auto will-change, but at the very least, it should either be configurable (default auto) to turn it off or Framer Motion would have to remove it automatically when a transition ends. Similar to how GSAPs clear: all property works. Come to think of it, something like clear: all would be awesome.