I am running into a weird issue with chrome when implementing react-reveal. What is happening if the animation is not running when you scroll down the page, until you stop and then the animation runs as expected. Has anybody had any experience with this issue? Cheers in advance
Implementation
So i simply made a fading div component, something like
class FadingDiv extends Component {
...
render() {
return (
<Fade>
<div className={this.props.className}>
{children}
</div>
</Fade>
)
}
}
And then simply switching out the div
tags with FadingDiv
where i want to implement the effect. This works great with safari and firefox, but (suprisingly) chrome is giving me issues. Any help would be massively appreciated, i feel a bounty incoming.
So looking over the issue posted in the react-reveal
package, and the related loading optimization issue they referenced, it looks likely that it's an issue with how Chrome prioritizes the loading and/or rendering of elements.
As mentioned in the second thread, there are a variety of hack-type fixes that might be able to alter Chrome's prioritization of events to favor the animation, depending on how the page currently is built. For instance, you might be able to explicitly force events on scroll or scroll end to override defaults. Or you might be able to add attributes either to the element or its sibling elements that force them to identify at a higher or lower priority.
It looks like a lot of the material out there on exactly how Chrome prioritizes both loads and paints is dated, but here is an updated resource on loading priority and another one on rendering that might be helpful.
If there is another element putting pressure on the browser's rendering/painting and deprioritizing the one under discussion, you could diagnose where the bottleneck is using Chrome's dev tools to track the timing of paints. (More about that here and here and here.) It looks like the diagnostics available are pretty great: they can get pretty detailed and include tracking priority.
Another thing you could try using is the CSS will-change property. It's another hack-type fix, but it looks like it can also be used to override performance defaults to favor an element with an upcoming animation.
Depending on the goal for how the page loads and what the other elements are, hopefully some of this helps to diagnose the bottleneck, and from there alter the prioritization enough to get the behavior you want.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With