Changes

This PR is the final PR in this refactor. After having introduced simpler internal types and migrating the Lottie type to use them, we can now introduce the LottieRenderer type to further refactor the bloated Lottie type.

This moves all rendering logic out of the Lottie type and into its own dedicated space. On top of this, engine management has also been separated into its own Engine type.

Splitting rendering logic into its own type

The original API for Lottie rendering included rendering inside the Lottie type. This was available via the renderFrame(at index: Int, into buffer: Buffer, stride: Int, size: CGSize, crop: CGRect? = nil) function.

There are some limitations for designing the API in this way:

• Separation of concerns: Internally we have a Canvas which handles the buffer and sizing details. Yet we have separate objects (Animation/Picture) for handling setting the animation frame index and the picture crop details. This means that is becomes tricky for the Lottie type to handle the lifecycle of all these internal objects. Here we have a clear separation we can make to match this desired functional separation of the Canvas details versus animation/picture details. Hence, LottieRenderer.
• Function parameter bloating: As you can see, the more functionality we want to add to our rendering calls means we need to add more parameters to this function. If we separate out the constants to this function (buffer, stride, size), we can significantly reduce how many parameters we have to pass in to our render call.
• Using the same buffer for each render pass: There was actually a bug in this code that meant that the first buffer you passed to the renderFrame function was the only buffer targeted to the internal Canvas. So if you used a different buffer on subsequent renderFrame calls, they wouldn't be filled with pixel data. This was also highlighted in a previous comment by @rlaguilar here.

Thus, we have now created the new LottieRenderer type. The LottieRenderer is responsible for two things:

1. Setting up a Canvas of a desired size that points to a buffer.
2. Provide the ability to render Lottie frames into that buffer.

/// Shorthand alias for the buffer type, representing image pixel data in a mutable pointer to UInt32.
public typealias Buffer = UnsafeMutablePointer<UInt32>

/// Object used to load and render Lottie frames.
public class Lottie {
    ...
}

/// Object responsible for rendering a Lottie animation using ThorVG.
public class LottieRenderer {

    /// Initializes the LottieRenderer with a specific Lottie object, engine, size, buffer, and stride.
    /// - Parameters:
    ///   - lottie: The `Lottie` object containing the animation to render.
    ///   - engine: An optional `Engine` object to use. If not provided, the default engine configuration is used.
    ///   - size: The size of the rendering canvas. This size determines the final size of the rendered Lottie content.
    ///   - buffer: A buffer to hold the rendered pixel data.
    ///   - stride: The number of bytes in a row of the buffer.
    public init(_ lottie: thorvg_swift.Lottie, engine: thorvg_swift.Engine = .default, size: CGSize, buffer: thorvg_swift.Buffer, stride: Int)

    /// Renders a specific frame of the Lottie animation, with cropping and rotation.
    /// - Parameters:
    ///   - frameIndex: Index of the frame in the animation.
    ///   - contentRect: Specifies the area of the content to be rendered. This rectangle defines the portion of the animation that should be visible in the final rendered frame, scaled to fit the `LottieRenderer` size.
    ///   - rotation: Rotation angle in degrees to apply to the renderered frame.
    public func render(frameIndex: Int, contentRect: CGRect, rotation: Double = 0.0) throws
}

Engine management

A note on how we manage the ThorVG Engine. Previously, every time a Canvas was created, we were initialising the ThorVG engine. The ThorVG engine only needs to initialised once, and not doing so hinders performance.

Thus, we've introduced a new Engine type that provides a default singleton instance, running on a single thread. This default instance is used as the default parameter to the LottieRenderer initialiser.

/// A Swift wrapper for managing ThorVG's engine initialization and termination.
public class Engine {

    /// A default instance of `Engine`, running on the main thread.
    public static let `default`: thorvg_swift.Engine
}

Larger refactoring

As mentioned, this is part of a larger factor across the entire Swift wrapper. This is the final PR, introducing LottieRenderer.

Look at the PR train below for more details.

PR Train 🚂

1. Refactoring Swift Wrapper: Introduce internal Swift types #9
2. Refactoring Swift Wrapper: Refactor Lottie type #10
3. Refactoring Swift Wrapper: Introduce LottieRenderer #11 <- YOU ARE HERE