Support cancellation when saving

[rickbrew]

I don't think saving supports cancellation -- if you try to save an image at, e.g. Very Slow, and then either 1) change settings, 2) click cancel, or 3) click OK, you have to wait for the initial save operation to complete.

[0xC0000054]

...you have to wait for the initial save operation to complete.

That is correct. AOM does not currently provide a progress reporting API for the encoder, so the progress reporting / cancellation step occurs before sending the encoded frame back to Paint.NET.

I am not sure why AOM does not have a progress reporting API, WebP is also a Google-backed project and it has one. Hopefully one will be added in a future release, but it does not look like there are any issues in the AOM bug tracker for an encoder progress reporting API.

[rickbrew]

Does it do all of the compression in-memory? There's no way to hook it in any way?

For some codecs, throwing an exception from Stream::Write() can do the trick.

So unless you can provide some kind of callback, your best shot is to host it out-of-process and terminate it when cancellation is needed. (don't terminate threads!) And that can be a lot of work.

[0xC0000054]

Does it do all of the compression in-memory?

I believe so.

There's no way to hook it in any way?

Not any easy ones. It would require changes to the AV1 encoder and the public AOM encoder API. I am considering opening an issue on the AOM bug tracker, the people there would be able to provide better information on if an encoder progress reporting API is feasible to implement.

So unless you can provide some kind of callback, your best shot is to host it out-of-process and terminate it when cancellation is needed. (don't terminate threads!) And that can be a lot of work.

That would be a lot of work. I have no idea how I would implement the IPC required for hosting the encoder out-of-process.

[rickbrew]

IPC in this case is probably done with a combination of ...

• Hoist the encoder into a command-line EXE that takes parameters
• One of the parameters is a HANDLE for a shared memory section and maybe another for some kind of event signal handle. See SingleInstanceManager for an example of shared memory, and UpdateMonitor for an example of passing a HANDLE to an external process (and be sure to inspect the code that "calls" it!). It's certainly ugly, but not a hack.

But I wouldn't rat-hole on this too much unless your dopamine compass is strongly pulling you in this direction. PDN should really host all FileTypes out-of-process. Some day ...

edit: fixed a typo. should be SingleInstanceManager, not SingleUseCriticalSection

[rickbrew]

Although for the IPC you'd probably want to use a pipe.

Still a big huge ball of crazy that's nice to be avoided if possible.

[0xC0000054]

I opened a feature request for a progress reporting / cancellation API on the AOM issue tracker. https://bugs.chromium.org/p/aomedia/issues/detail?id=2837