Skip to content

Conversation

@X-Ryl669
Copy link

@X-Ryl669 X-Ryl669 commented Dec 15, 2021

This actually allows performing rendering in passes and does not require a width * height * 4 bytes buffer anymore.

On limited memory MCU, this will allow rendering a large animation by trading off memory for CPU consumption instead.

Typically instead of this rendering loop:

   buffer = new uint8[stride * h]; // Huge
   for (i = 0; i < totalFrame; i++) {
        lottie_animation_render(animation, i, buffer, w, h, stride);
   }
   sendBufferToDisplay(buffer);

This allows this kind of loop:

   const int lineCount = 10;
   buffer = new uint8[stride * lineCount]; // Small
   for (i = 0; i < totalFrame; i++) {
       for (l = 0; l < h; l += lineCount) {
          lottie_animation_render_partial(animation, i, buffer, w, h, l, l+lineCount, stride);
          sendBufferToDisplay(buffer, l);
      }
   }

The overhead is higher than a single rendering (mainly, clearing the buffer and computing the clip path n times) but allow to have a lot smaller buffers so it's very useful for limited/embedded system with almost no RAM like ESP32 or STM32.

…ndering in passes

and does not require a `width * height * 4` bytes buffer anymore. On limited memory MCU,
this will allow rendering a large animation by trading off memory for CPU consumption instead.
@X-Ryl669 X-Ryl669 mentioned this pull request Dec 15, 2021
3 tasks
@X-Ryl669
Copy link
Author

CI errors are not related to my changes. You'll need to fix the CI pipeline to include the uint and uchar typedef that's used in the elsewhere in the code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants