Performance issue with Mutate in WASM

[TomatorCZ]

Prerequisites

• I have written a descriptive issue title
• I have verified that I am running the latest version of ImageSharp
• I have verified if the problem exist in both DEBUG and RELEASE mode
• I have searched open and closed issues to ensure it has not already been reported

Description

I use Blazor WebAssembly for that. I create a new blank image (1920x1080) and change the background color with Mutate, but Mutate took about 32 seconds in Debug and 23 seconds in Release mode.

Steps to Reproduce

Create a new Blazor WebAssembly project
Add the code below to a Razor page.

{
	protected override void OnInitialized()
	{
		base.OnInitialized();
		System.Diagnostics.Stopwatch stopWatch = new System.Diagnostics.Stopwatch();
		stopWatch.Start();
		var a = new SixLabors.ImageSharp.Image<SixLabors.ImageSharp.PixelFormats.Rgba32>(new Configuration(), 1920, 1080);
		stopWatch.Stop();
		Console.WriteLine(stopWatch.ElapsedMilliseconds);
		stopWatch.Restart();
		a.Mutate(o => o.BackgroundColor(Color.Black));
		stopWatch.Stop();
		Console.WriteLine(stopWatch.ElapsedMilliseconds);
	}

}

Open the browser console where the results are displayed.

System Configuration

• ImageSharp version: 1.0.3
• Other ImageSharp packages and versions:
• Environment (Operating system, version and so on): Google Chrome 91.0.4472.124, Windows 10
• .NET Framework version: net5.0
• Additional information: I found a related issue

[br3aker]

While this doesn't fix this particular issue, have you tried Image ctor from given color as a workaround?

var img = new Image<Rgba32>(1920, 1080, new Rgba32(0, 0, 0, 255));

[JimBobSquarePants]

Yeah no, this should have been a discussion not an issue. WASM doesn't have SIMD yet.

[tocsoft]

FYI @TomatorCZ .BackgroundColor() is for converting transparent backgrounds of existing images, however what it looks like from your example is you would be better of using any of theses other APIs:

1. The constructor overload that takes a Color,
2. .Clear(color)

The reason BackgroundColor() will likely be slower is because it has to process each pixel independently rather that just flood filling the images pixel memory with a single color value which is what the other 2 do.

[antonfirsov]

@TomatorCZ afaik WASM is interpreted in .NET 5.0 blazor by default, thus uncapable to run any computation-intensive managed code efficiently, including image processing. This should improve for next version with AOT (see dotnet/runtime#44316), but I think it will be a very long way until performance will be acceptable. We recommend to move your image processing code to a server-side component.

[h3x4d3c1m4l]

@TomatorCZ You might want to try switching to .NET 6. The AoT compilation to native WASM already works very well...

Instructions can be found here. Although these instructions are written for .NET 6 preview 4 I found these exact instructions to be still working as of .NET 6 preview 6.

[stephajn]

I'm sorry to give an older issue (and a closed one at that) a bump, but I'm just curious if as of the release of .NET 6, if ImageSharp is now a viable option to use in browser with Blazor WASM, or if this kind of work should still ideally be done at the server. Or, is it now a case of using AOT in release builds to get around any performance issues?

[JimBobSquarePants]

I know MS did a lot of work improving performance for .NET 6 and even demoed those improvements using ImageSharp. However I haven't performed any benchmarking.