Consider to support the next Interface for user custom memory allocator:

//register a user memory allocators
struct Initializer::Allocator
{
        void* (*alloc)(size_t);
        void* (*calloc)(size_t, size_t);
        void* (*realloc)(size_t, size_t);
        void (*free)(void*);
};

//initialize
static Result Initializer::init(uint32_t threads = 0, const Allocator& allocator);

Why use this structure?

Customization enables deeper optimization
High-performance engines and renderers often replace malloc() with custom allocators (e.g., memory pools) to avoid bottlenecks. ThorVG can similarly benefit from tailored memory strategies for complex animations and real-time UI rendering.

Platform-specific allocator optimization
Different platforms benefit from different allocators (e.g., ashmem on Android, objc_alloc on iOS, arena allocators on embedded systems).

Improved debugging and memory tracking
Custom allocators allow precise tracking of memory usage, detecting leaks, and logging allocations for analysis.

Maybe 1–2 additional instructions are required per memory call, though they are likely negligible. A performance comparison before and after is needed to confirm.