Anton Firszov

Almost forgot the most important question regarding the proposed design: What are our plans for the encoders? Do we plan to remove the disparity? If yes, can we put together...

@TodesBrot is this an ICO-specific use case? Or do you know other cases where a BMP stream is provided without a header?

Thanks @benaadams @saucecontrol for the suggestion! I also considered this idea, but discarded it, since we can not use explicit aligned Load/Store intrinsics without guaranteed alignment. I guess it's no...

Our internal primitives usually process data in batches, for example: https://github.com/SixLabors/ImageSharp/blob/4aed9f41d6feecd43b78f93db8b3343ee22f8d72/src/ImageSharp/Common/Helpers/SimdUtils.cs#L98 Such an batch is typically called for a pixel row (which is a lot of data), then the buffer...

Ah right! I completely forgot for a moment that L2 & L3 is also a thing 😅

@saucecontrol btw `GUARDRAILS` is a great trick, we should adapt it in debug runs, I wonder how many security bugs would that unveil.

Note that the referenced netvips benchmark is quite atypical for Resize. Users usually downscale much more than 90%, so I wouldn't worry *that* much for the encoder being a bottleneck....

Ah yeah saving 4K JPEG must be very slow indeed. (Hope noticeably better with #1508). What I mean is that we got away with a slow encoder this long because...

Not a pro with this tool, but if I'm reading it right, [RowOctet constructor](https://github.com/SixLabors/ImageSharp/blob/a1784a67bf492b1b02e99655a39aa5e5acf81988/src/ImageSharp/Formats/Jpeg/Components/RowOctet.cs#L27-L39), and [Emit](https://github.com/SixLabors/ImageSharp/blob/0e0dc2ae9cafcdf5bde9d185919cf073ddf4f186/src/ImageSharp/Formats/Jpeg/JpegEncoderCore.cs#L316-L348) are the new bottlenecks. @tkp1n can you confirm? Here only the `RowOctet` thing is...

@JimBobSquarePants I think we can close this in favor of a general JpegEncoder perf tracking issue.