Performance issue with transitions causing CPU spikes

[lmatteis-wm]

Here's an example of a simple smooth animation of a jpg image:

class BasicUsageExample extends lng.Application {
    static _template() {
        return {
            LilLightningA:{ x: 50, y: 0, src: 'https://images.unsplash.com/photo-1647067867267-e01d98462f3c?ixlib=rb-1.2.1&ixid=MnwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8&auto=format&fit=crop&w=2066&q=80'},
        }
    }

    _handleRight(){
        this.startTransitions();
    }
        
    startTransitions(){
        this.tag('LilLightningA').patch({ x: 50, alpha: 0.001, scale: 1.03 });
        //Start transitions
        this.tag('LilLightningA').patch({
            smooth: {
              alpha: [1, { duration: 2 }],
              scale: [1, { delay: 1, duration: 10, timingFunction: 'ease-out' }],
              x: [0, { duration: 1, timingFunction: 'ease-out' }]
            }
        });
    }
       
}

const options = {stage: {w: window.innerWidth, h: window.innerHeight, useImageWorker: false}};
const app = new BasicUsageExample(options);
document.body.appendChild(app.stage.getCanvas());

(simply copy & paste the above code into here to test it https://rdkcentral.github.io/Lightning/docs/transitions/overview)

I've ran this simple transition using 6x CPU slowdown (via devtools) on my Chrome and am getting a quite busy CPU flamechart:

This causes stutters on TV devices that are even more limited CPU wise.

I tested the same kind of animations using for instance PixiJS (another 2d WebGL framework) and the CPU readings are much less busy:

Is there something I'm missing from the code? Or is there something limiting our animations performance within Lightning?

[g-zachar]

@lmatteis-wm This is likely caused by Lightning's overhead in general and is something very hard to improve upon at this point. When running animations, each frame has to be recalculated to some extent and rerendered.

Simple PixiJS application is likely to outperform Lightning in basic rendering tests (since it doesn't have intermediate layer overhead) but you would likely run into CPU performance problems when trying to build these layers yourself.

[lmatteis-wm]

@g-zachar would it make sense to create a custom shader instead?

[g-zachar]

@lmatteis-wm Hard to be certain, but such shaders would probably have limited functionality due to lack of access to render tree. You can check spinner shaders' performance on your platform - it updates WebGL context every frame - and see how much of an improvement (if any) there is compared to using animations.

Best regards

[lmatteis-wm]

@g-zachar just tested the SpinnerShader2 within the Lightning repo.

Still getting a bit too much CPU work spikes caused by the drawFrame for something I would expect being little to almost no cpu work. The example is just interpolating some values for the shader. What's causing all this work?

EDIT

I also just tested a single SpinnerShader2 without any animations (sending also 0 as time to the shader) and am still getting a spiky CPU. Seems like it's something about Lightning's diffing causing this? Ideas? Note how the below image is static and not animating

When instead I remove the shader and just add a normal component with some text the CPU finally frees up:

[g-zachar]

@lmatteis-wm

In the case of the animated spinner, each frame is different and needs to be rendered anew, therefore the rendering path is activated to some extent. In the case of an empty component, there are no changes on the screen so the rendering path is not active, therefore the CPU is not being used.

Shader updating uniforms is the lowest denominator I can think of and if it already causes performance issues then it's hard to think of any optimization at this point.

Still getting a bit too much CPU work spikes caused by the drawFrame for something I would expect being little to almost no cpu work.

There are many factors to this: since the scene is rendered at 60 FPS, that gives roughly 17 ms of CPU time for each frame. JavaScript is many times slower than native languages like C and working with OpenGL context usually requires quite a number of operations. The lack of sufficient processing power on lower-end platforms is not only caused by the CPU itself but also very high overall load caused by external processes.

Best regards