Anton Firszov

I definitely want this! :) Our `ImageSharp.Benchmarks.csproj` project currently targets net461 only. It would be nice to have something that utilizes all those `[***Job]`-s. I'm really interested in mono numbers....

@dannyrb is this something you are still interested in?

@Lectem thanks for reaching out! Good question. Here are the things which are critical to make such an external contribution useful for us: - No noise from CI infra. Normally...

@JimBobSquarePants hmm .. originally I wanted to polish + standardize our memory management in the next few months, but there are many uncertainties around that topic, so maybe I'll grab...

There is a lot in there, have to pull down the code and do a proper review. Couldn't do it this last week, but will definitely take a look this...

One more concern: We should think a bit more about the specialized decoder cases from user perspective. https://github.com/SixLabors/ImageSharp/discussions/2091#discussioncomment-3036607 considers it done with the following: ```C# new JpegDecoder().DecodeSpecialized(JpegDecoderOptions ...) ``` However:...

> A [CancellationToken](https://docs.microsoft.com/en-us/dotnet/api/system.threading.cancellationtoken?view=net-6.0) enables cooperative cancellation **between** threads, thread pool work items, or [Task](https://docs.microsoft.com/en-us/dotnet/api/system.threading.tasks.task?view=net-6.0) objects. @br3aker this wording implies to me that `CancellationToken` was designed for multi-threaded / asynchronous scenarios....

> Every time I look at stateful decoders mixed with general options it looks ugly. plus I really want to avoid passing a decoder to either of the `Load/LoadAsync` methods....

I'm not suggesting to remove it from the Decoder API. That's the best way for us to implement the cancellation, so makes total sense to pass it to decoder implementations....

Cool! Will do another round of review on Monday.