Can you opt-out of "Hardware-accelerated" animations?

[joealden]

Hey,

I understand that shifting animations (that can be) to the GPU (presumably via WAAPI) has its pros regarding performance, but when I went to update our framer-motion dependency at work from 7.6.9 to 8.4.2, I noticed some problems that I believe are likely due to the recent changes regarding hardware acceleration, and I'm thinking that they might just inherently be problems with the extra "work" of shifting stuff CPU <---> GPU?

For this reason, I'm wondering if there is a way (or a way would be considered) to disable hardware acceleration for certain animations, or just globally?

To document the issues we were seeing, it was mainly around a Tooltip component we have that uses the MotionValue returned from useSpring as an opacity value, as well as to nicely mount and unmount the tooltip contents (only unmounting after the animation is complete via an onChange handler).

When updating from 7.6.9 to 8.4.2, we saw the following differences/problems:

1. The springs config included a duration value of 150, which worked fine on 7.6.9 , but resulted in no visible animation occurring on 8.4.2 (it was just popping in and out like no animation was happening). Increasing the duration to around 500 seemed to mimic the previously set 150 value, so this does seem like a possible workaround, but this then makes me worry about other animation timings in our app (and that they could change depending on what properties are animated).
2. The unmounting timing no longer seemed consistent, as sometimes a tooltip would stick around in a low opacity state for about a second or so. This was most obvious in a component we have that have icons for tabs, and the tabs show a tooltip on hover, so when quickly moving your mouse between the tab items, there would be noticeable "ghosting" like behaviour. For this in particular, I'm wondering if this is some kind of WAAPI scheduling issue?

As mentioned above, I'm thinking this might be a WAAPI issue more so than a framer-motion issue (do note that I did test this in both Firefox and Chrome, so it doesn't seem browser specific), so although it'd be great to have this work as it did before but be hardware accelerated, I'd also be happy to be able to opt-out of hardware acceleration (but be able to access the latest features of framer-motion by being on the latest version).

Let me know if anyone wants minimum reproductions of this!

Thanks!

[joealden]

@mattgperry any thoughts on this? Apologies for tagging you - just want to see if you think this would make sense to be converted into an issue or not (as the more I think about it, the more this seems like it could be a bug)?

[joealden]

@mattgperry FYI this is still a problem on the latest version at the moment (10.11.2).

[mattgperry]

Hey @joealden sorry I have never seen this, I think notifications here are going to my framer email which I have basically never looked at. I actually stumbled here via Google looking for ways to disable hw acceleration in WAAPI 😅 This was the top result.

Can you open a feature request for a MotionConfig perhaps if this is still a problem?

[joealden]

Haha no worries! Part 1 of what I mentioned above (the difference in percieved timing) is still a "problem" (we ended up doubling our duration to make it feel similar), but part 2 seemed to fix itself in a later version. Looking back at our commit history, we bumped to 11.0.3 from 7.6.9, so I presume something between 10.11.2 and 11.0.3 fixed the problem, or maybe browsers fixed something on their end (maybe there was a spec update)?

Either way, this is no longer preventing us from upgrading, so I don't see it as a pressing feature we'd want anymore!

looking for ways to disable hw acceleration in WAAPI

Did you find anything? 😅 - and what was the reason behind you looking? Have you/framer run into problems with it? Because if there is a simple way to disable it without having a seperate code path that isn't WAAPI, maybe it could still be something to add an option for?

[mattgperry]

Well specifically what I was after was a way to animate transform with WAAPI without bumping the element to a GPU layer. Specifically to update the value without triggering style recalculations. Someone has made a humongous Ticker in Framer, the element in question is both a huge GPU layer and also contains many elements.

I haven't figured it out yet, even trying things like animating transformX(calc(100px)) to de-opt the animation to the main thread - I think if there's any WAAPI animation on transform then it'll still become a GPU layer even if the animation itself can't be hardware accelerated. So the next thing I want to try is to see if animating CSS variables instead will be more performant (even though usually they're not)

[mattgperry]

So actually it turns out by removing the style recalculations the CSS variables were faster, even though they trigger paint. I'm still unsure why the style recalcs are triggered though from just a simple .style assignment