Using the new Targetsize decoding

[Webreaper]

Hey, so I've upgraded to v3.0 and changed my load to use the new TargetSize config. Processing 1,800 images all of about 9MB, 4600x3600 res approx), specifying a targetsize of 800x800 as the bounded box to decode. Each image is loaded at 800x800, then resized to 3 increasingly smaller resolution thumbnails and then all 4 are saved.

I'm seeing almost zero performance gain when loading.

• ImageSharp v2.0: 1872ms (Load average 1217ms, Resize average: 549ms)
• ImageSharp v3.0 with Targetsize Decode: 1445ms (Load average 1275ms, Resize average: 137ms)
• SkiaSharp: 105ms (Load average 88ms)

You can see that v3 is slightly faster, but only because of the resize, not because of the load time.

The code change is here: Webreaper/Damselfly@e78b517#diff-bc7171db6cb3f840952a6f899a5776dc3449e630301b9b488c8025c39dd06411R67

What am I missing? I was expecting to see the load time drop significantly - because the decoder would do a progressive decode for the image. Am I right in understanding that targetsize is basically saying "decode the closest size to fall within these bounds"? Or is it different to that?

Do I need to do something smarter to make the use of the TargetSize more optimal - similar to the GetScaledDimensions call that I use when I do a scaled load with SkiaSharp (as here)?

[JimBobSquarePants]

I’m on my mobile so can’t read your code sample but it sounds like you’re doing the operation 2X?

Using the target size with the general decoder options will always yield the exact size you want. We do a first pass internally using the decoder, then follow up to resize the difference.

What platform are you running on? We should be much closer than those numbers.

[Webreaper]

Ah, okay so unlike Skia, where you find the closest size to decode, and then resize to exact dimensions you want, with ImageSharp I should pass in the precise target size and it should do both steps for me? In that case I might be doing it wrong, so let me have a play.

All these tests were run on my M1 Mac.

[JimBobSquarePants]

Yeah it does both for you. You can opt out of that behaviour using specialist decoding.

M1… Ok the numbers are making sense now.
That chipset requires intrinsics from the Arm64 class. We’ve only just managed to get hold of a CI platform that allows us to test implementing those intrinsics so have only just begun to add implementations of algorithms based on them. The jpeg decoder contains none as far as I’m aware.

On an x86 device with access to Avx intrinsics we’d be faster than Skia.

https://developer.arm.com/documentation/102753/0100/?lang=en

[Webreaper]

Okay, cool. I normally run Damselfly on my Intel NAS so it sounds like it'll get the advantage there. I'll try and do some speed tests on Intel if I get time.

Thanks, as always!

[JimBobSquarePants]

No worries. Let me know how you get on.