Unexpected resizing behaviour (slow/delayed/animated)

[dwood023]

The player exhibits some unexpected behaviour when it resizes - it appears to smoothly animate to its new dimensions over a period of about 180-220 milliseconds.

I don't know if it's reasonable to call this a bug, but the current behaviour is unfortunate for our use case, as we have a requirement to animate the player's size in arbitrary ways that don't synchronise with the apparent default animation behaviour.

More details

Currently, the animations we have implemented result in the player "lagging behind" its parent, leaving such obvious signs as parent borders being under or over-filled, and the player shrinking or growing at a rate that is slightly out-of-phase with other changing UI states.

Steps to reproduce

I've modified the SimpleExample component in the project examples to demonstrate the behaviour. See this fork (specifically, this commit) for the code.

Here is a GIF of the demo running on a simulator - the expected behaviour is shown by the orange view, whose size is shown to update instantly. The player's width is determined by the exact same value as the orange view, but acquires its new size slowly, making it appear to "lag behind". This example is analogous to our use case in which the player's size is out of sync with its parent or surrounding elements whose sizes are changing.

For convenience, here is the code to produce the component rendered in this example:

import * as React from 'react';
import { View } from 'react-native';
import IVSPlayer from 'amazon-ivs-react-native-player';

const URL =
  'https://fcc3ddae59ed.us-west-2.playback.live-video.net/api/video/v1/us-west-2.893648527354.channel.DmumNckWFTqz.m3u8';

const growthRate = 10;
const growthInterval = 1000;

export default function SimpleExample() {
    const [width, setWidth] = React.useState(10);

    React.useEffect(() => {
        const interval = setInterval(() => setWidth((width) => (width + growthRate) % 100), growthInterval);
        return () => clearInterval(interval);
    }, []);

  return (
    <>
        <View
            style={{
                position: 'absolute',
                top: 0,
                bottom: 0,
                left: 0,
                right: 0,
                alignItems: 'center',
                justifyContent: 'center',
            }}
        >
            <View
                style={{
                    aspectRatio: 1.78,
                    width: `${width}%`,
                    backgroundColor: 'orange',
                }}
            />
        </View>

        <IVSPlayer
            style={{
                width: `${width}%`,
                alignSelf: 'center'
            }}
            muted
            streamUrl={URL}
            testID="IVSPlayer"
        />
  </>
  );
}

Expected behavior

For our use-case, it would be preferable for the player to instantly acquire the size prescribed by its props, so we can precisely control its size without worrying about the apparent default animation lagging behind.

Device

Tested on real iPhone 13 device, as well as an iPhone 13 Simulator running iOS 15.4.

[maxstoller]

Hi @dwood023, thanks for the very detailed bug report and sample code. We'll take a look and get back to you here.

[maxstoller]

As you demonstrated, the underlying iOS IVS player SDK currently animates the layer during a size change. We are evaluating making this configurable in a future release, but I don’t have a timeline to share at the moment. Thanks again for the report.

[riderx]

Hey @maxstoller any update on this ?

[maxstoller]

I don't have an update on this one, unfortunately. Thanks.

[riderx]

do the code of the player is open source, i'm willing to do a PR to allow it

[maxstoller]

The iOS and Android player SDKs are not open source, but thank you for the offer.

[Bowlerr]

@maxstoller any updates on this? the ability to disable the default animation would be great.

[maxstoller]

Hi @Bowlerr, unfortunately I do not have an update on this one. We have been prioritizing other issues.

[hirbod]

Can I ask once again?

[maxstoller]

Hi @hirbod, we do not currently have plans to change the current behavior.

[hirbod]

It would be nice to have a prop to disable the animation. It looks pretty odd sometimes.