DotLottieReact shows empty canvas for a while when it becomes intersecting state

[sni-J]

Overview

https://codepen.io/sni-J/pen/VwOopGY

forked from Getting Started, just added 100vh div above DotLottieReact

current	expected

150ms is not very long but lottie coming out of empty space is quite awkward.

Reason

1. IntersectionObserver of DotLottieReact has its own 150ms debounce on freeze/unfreeze with threshold: 0
   • https://github.com/LottieFiles/dotlottie-web/blob/6e15246dcb21acaf5df7458b78475bc3d1290694/packages/react/src/use-dotlottie.tsx#L119-L135
2. Canvas is only rendered visible area in viewport (could not find why) In Custom Playback Controls example,
   • Pause in this viewport,
     
   • and scroll upward
     

So, it acts like this...

Initial (placed outside of viewport, or !intersecting in IntersectionObserver word)

• it freezes with canvas nothing drawn

Become visible (intersecting: false -> true):

• it waits 150ms debounce (still frozen)
• empty canvas is visible
• unfreeze

Become invisible (intersecting: true -> false):

• since canvas is placed outside of viewport so empty canvas is drawn
• then trigger IntersectionObserver, freeze with empty canvas after 150ms debounce

(Repeat)

Solution Suggestion

1. Remove debounce IntersectionObserver won't need debounce in most case IMO

2. disableFreezeOnInvisible I have no idea how heavy each draw is, but maybe this can cover lots of simple cases

3. or any other better solutions

Workaround based on current implementation

• manually pause with IntersectionObserver + threshold: 1
  • pausing before freeze can prevent drawing empty canvas
  • but it will pause too early and last frame remains while 150ms unfreeze debounce
• manually unfreeze with IntersectionObserver + threshold: 0, before debounced unfreeze applied
• or... prevent freezing by adding freeze event listener which unfreeze right away
  • what I did in my case, regardless of performance and unknown side effects, since I had only one small simple lottie on page
  • 'rendering only part of canvas' still remains so if you scroll fast enough you can see partially drawn lottie, as you might see in the video above, but better than before

Labels

• [x] Add the Type: Bug label to this issue.

[theashraf]

Thanks @sni-J for the detailed issue and suggestions.

I agree with you; the IntersectionObserver callback shouldn't get debounced. We will address this issue promptly in the next release.

Your suggestion for disableFreezeOnInvisible makes sense as well. Also, it shouldn't be the responsibility of the dotlottie-react to handle this. We can move this partial rendering behavior to the dotlottie-web main animation loop instead of on each frame event. This change would ensure that if the animation is running at a low FPS, the partial rendering is not coupled with the animation speed. For example, I think this adjustment should fix the issue where fast scrolling can cause the animation to appear clipped.

Even the offscreen performance optimization, I think, should be handled and live in the core dotlottie-web.

For now, we will:

• Remove the debounce - Add disableFreezeOnInvisible prop

Other improvements will be addressed in the future.

[theashraf]

@sni-J, as a workaround for now, you may listen for the freeze event and immediately unfreeze when it occurs:

<DotLottieReact
  dotLottieRefCallback={(dotLottie) => {
    dotLottie?.addEventListener("freeze", () => {
      dotLottie?.unfreeze();
    });
  }}
  src="https://lottie.host/63e43fb7-61be-486f-aef2-622b144f7fc1/2m8UGcP8KR.json"
  loop
  autoplay
  style={{
    maxWidth: "600px"
  }}
/>

[theashraf]

@sni-J debounce has been removed on dotlottie-react v0.7.1

[theashraf]

@sni-J partial canvas rendering has been temporarily disabled in dotlottie-react v0.8.3. This feature will be ported to dotlottie-web in a future release, with a configuration option to disable the optimization if needed.

This should resolve your issue. Let me know if you're facing any other problems. Thanks!