Question about performance and FFI support

[WutangNailao]

Hi 👋，

Thanks for maintaining this great library — it’s very useful to have a pure-Dart image processing solution that works across Dart VM, Flutter and Web.

I have a question regarding implementation choices and performance:

Currently the library is implemented entirely in Dart (including codecs and pixel manipulation). That makes it extremely portable, but for many performance-sensitive use cases (e.g., large images, decoding/encoding, resizing) pure Dart ends up being significantly slower compared to native libraries — even when running in isolates.

Given that the Dart ecosystem now has support for dart:ffi and tools like ffigen, allowing bindings to native libraries (e.g., libjpeg-turbo, libpng, libwebp, or even optimized C/C++ image algorithms), I’m curious about the rationale for not offering an optional FFI-backed implementation or plugin variant to accelerate the heavy parts of this library.

1. Has using FFI been considered?
   – Such as optionally calling into native image codecs or optimized routines for pixel operations.

2. Are there technical limitations or project scope decisions that make FFI integration undesirable?

3. Is it a deliberate design philosophy to keep everything in pure Dart for maximum portability and simplicity?
   – If so, is there any plan or openness to a separate FFI-accelerated extension package in the future?

Many other packages (e.g., imagekit_ffi) already explore FFI for faster encode/decode, showing this approach is feasible.

I’d love to understand the motivations and whether there’s room for performance enhancements while keeping the current API usable.

Thanks!

[brendan-duncan]

Hi there,

1. Yes, FFI has been considered.

2. It's not so much a technical limitation, as a maintenance concern. I maintain this library with very little free time, because I enjoy helping the people that find it useful. It's already a very difficult task keeping it updated and addressing bugs. FFI adds considerable maintenance cost that I'm not ready to take on, so instead I do the best I can with what's here.

3. Indeed, the design philosophy is definitely around portability and simplicity. I wrote this library 13 years ago, and at that time there was no FFI, Flutter, or really much of anything. There have been people using the library for all sorts of purposes, and I've tried to keep it simple at the cost of performance, though I do the best I can with performance given the limitations of Dart.

As for plans, I don't have any. I wish I did, I know people would appreciate improved performance for their non-web apps, which is probably most of Dart's use these days. I just don't have the time to do anything like that. Would I accept a PR to add some FFI-based native implementations? I'd have to do that carefully, sine I'd be on the hook for maintenance. Would I be open to a separate FFI-accelerated extension package? Absolutely, I'd love that.

I hope this helps, and thanks for your interest.

[WutangNailao]

Hi, thanks for the discussion around this topic.

I’d be very interested in working on an optional FFI-based acceleration layer for this library if it aligns with the project direction.

I fully understand that one of the core strengths of this project is its pure-Dart implementation and cross-platform portability, and I have no intention of changing that foundation. My idea would be to explore an approach such as:

• keeping the current pure-Dart implementation as the default
• implementing FFI acceleration as an optional, separate package (e.g. image_ffi)
• focusing only on performance-critical parts (decoding, encoding, pixel processing)
• ensuring it does not add maintenance burden to the core library

If maintainers think this direction makes sense, I would be very willing to take ownership of this effort, including:

• designing the architecture
• implementing the initial proof-of-concept
• handling ongoing development and maintenance

Please let me know if this would be considered in scope, and if there are any specific concerns or design constraints I should be aware of before starting.

Thanks again for the great work on this project!

[brendan-duncan]

Thinking about it more, perhaps having a unified package might be less confusing than separate packages. If you want, you could submit an initial PR that implements a single feature using a native library and FFI bridge. For the platforms that support it, it could use the FFI implementation. The PR should include developer documentation for how the native libraries are compiled for the platforms that they support. Implementing a commonly used feature with a native library, such as libjpeg, or a commonly used transform like resize, would be a good starting point. Another important factor is that it can't include any new pub dependencies unless absolutely necessary. The developer and maintenance documentation would be a very important part of this PR. Keep in mind that besides the occasional PR contributor, "maintainers" is one person, myself.

Of course, if you want to do your own thing, you are welcome to.

[WutangNailao]

Hi, thanks again for the discussion.

I’d be very happy to take long-term ownership of this effort — not just an initial PoC, but ongoing development, maintenance, and support for an optional FFI/native acceleration layer, if it aligns with the project direction.

After thinking more carefully, I believe implementing this as a separate package (e.g. image_ffi) would likely be the best fit, for a few reasons:

1. Cleaner dependency story
   Some users may not need native/FFI at all. Keeping it separate avoids making everyone carry extra FFI dependencies, build scripts, binary artifacts, increased package size, and platform constraints.

2. More flexible release cadence
   An image_ffi layer may need faster iterations to fix ABI/platform compatibility/build tooling issues. Decoupling releases means we don’t have to tie those updates to the higher-level Dart API versioning.

3. Easier maintenance and debugging
   FFI issues are often platform/build/ABI-related. Isolating them makes issue triage and root-cause attribution much clearer, and keeps the core image package simpler.

From a repository organization perspective, I would suggest keeping both packages in the same GitHub repository using a monorepo structure, where the pure-Dart image package and the optional image_ffi package coexist. This keeps development coordinated while still maintaining clear separation of concerns at the package level.

Regarding the native implementation strategy, I see three broad options:

• Rust as a shared native core (my current preference) — one reusable core across iOS/Android/Desktop with consistent behavior, exposing a stable C ABI to Dart.
• Platform-specific implementations (Swift/Kotlin/etc.) — leveraging platform APIs directly, but introducing duplicated logic and higher long-term maintenance cost.
• Binding mature C/C++ libraries directly — e.g. libjpeg-turbo, which offers excellent performance but increases multi-platform build and packaging complexity.

At the moment I’m leaning toward Rust, since it allows reusing the same core across targets while keeping behavior consistent.

I’d love to hear your thoughts on which direction you’d be most comfortable with, and whether there are any constraints or preferences I should consider before drafting a more concrete proposal.

[brendan-duncan]

You can feel free to implement a separate package. The license is MIT, which means you're free to do what you want, there's no restrictions on the code. I wouldn't want to do a monorepo, I like to keep things very simple. As for the language you choose, that's fully up to you. I personally am not a fan of rust, but there's certainly no reason you shouldn't use it. So, please do go forward, You don't need my permission to do any of this, and I'm certain many people would be very grateful for having a native execution option.

[WutangNailao]

Sorry for the long silence.

Before starting the upcoming FFI changes, I submitted PR #778 to introduce benchmark infrastructure and establish a performance baseline. This gives us a consistent way to compare performance before and after the FFI migration and helps catch regressions early.

[WutangNailao]

I’ve completed an initial native acceleration path for image transforms.

At the moment, the following native functions are implemented and wired through FFI:

• image_crop_rgba8
• image_resize_rgba8

The native implementation is written in Rust, and the package is set up to distribute these binaries in precompiled form, so end users do not need a local Rust toolchain for normal pub add image usage.

To support packaging and distribution of the prebuilts, I also added a build script here:

• tool/build_prebuilt_native.sh

The current integration is designed as an optional fast path:

• Dart code will try the native backend when the requested operation matches the currently supported cases
• unsupported cases continue to fall back to the existing pure Dart implementation

So this should improve performance for supported transform paths without changing behavior for existing users.

There is still room to expand platform coverage and supported pixel formats / transform variants, but the basic FFI + Rust + prebuilt distribution pipeline is now in place.

[brendan-duncan]

Thanks.
If it takes me a little while to get to this, it's not because I'm ignoring you, I've been quite busy with work and will get to this as soon as I get some free time again.

[brendan-duncan]

Pure-Dart portability (no FFI/native dependency) is a deliberate design choice for this package. Closing as a design-discussion question.

---

Closed as part of an automated issue-backlog triage. If you think this was closed in error, please reopen — and thanks for taking the time to file it.