Hey there! I totally get the frustration of seeing scaling performance tank when running in parallel—20x slower is definitely not ideal. Let's break down why this might be happening and look at some better approaches than the two you've tried so far.

First, Why Parallel Threads Are Slowing You Down #

Before jumping to fixes, let's clarify the root cause: 60 threads is likely way more than your CPU can handle efficiently. Most modern CPUs have 8-16 logical cores, so spawning 60 threads leads to massive context switching overhead. Each thread is fighting for CPU time, and if your scaling is touching GPU resources (like SKSurface), you're also adding GPU context contention on top of that. That's why individual scaling tasks take so much longer.

Better Scaling Approaches to Try #

1. Match Pixel Formats to Avoid Unnecessary Conversions #

Your current code forces SKColorType.Bgra8888 for the output, but if your source image uses a different format, ScalePixels or Canvas.DrawImage will waste cycles converting pixels. Always reuse the source's color and alpha types when creating the target:

SKImage src = (...);
var srcInfo = src.Info;
var destInfo = new SKImageInfo(width, height, srcInfo.ColorType, srcInfo.AlphaType);
using SKImage output = SKImage.Create(destInfo);
src.ScalePixels(output.PeekPixels(), SKFilterQuality.None);

This eliminates format conversion overhead, which can save a surprising amount of time, especially in parallel.

2. Use SKBitmap for CPU-Based Scaling (Avoid GPU Contention) #

SKSurface and hardware-backed SKImage rely on GPU resources, which are inherently harder to parallelize. Switching to SKBitmap (CPU-side pixel storage) avoids GPU context locking and contention across threads:

SKImage src = (...);
using SKBitmap srcBitmap = SKBitmap.FromImage(src);
using SKBitmap destBitmap = new SKBitmap(width, height, srcBitmap.ColorType, srcBitmap.AlphaType);
srcBitmap.ScalePixels(destBitmap, SKFilterQuality.None);
using SKImage output = SKImage.FromBitmap(destBitmap);

SKBitmap.ScalePixels is optimized for CPU execution and doesn't tie up GPU resources, making it much friendlier for parallel workloads.

3. Tune Thread Count to Your CPU #

Ditch the fixed 60 threads—instead, use a thread pool with a maximum thread count matching your CPU's logical core count (you can get this via Environment.ProcessorCount). Too many threads kill performance due to context switching; letting the thread pool manage execution, or limiting to 16-32 threads max, will drastically reduce per-task latency.

4. Reuse Objects with a Pool #

Creating and destroying SKImage, SKBitmap, or SKSurface objects in every parallel task adds GC pressure and allocation overhead. Implement a simple object pool to reuse these resources across tasks:

• Pre-create a set of SKBitmap instances with common target sizes (or resizeable buffers)
• Check out a bitmap from the pool when scaling, then return it after use
  This cuts down on expensive memory allocations and deallocations in your hot path.

Quick Comparison to Your Original Methods #

• Your Method 1 (ScalePixels) is solid, but fixing the pixel format mismatch will give it a noticeable boost.
• Your Method 2 (SKSurface + Canvas) is the worst for parallelism because it uses GPU surfaces—contention here is the biggest culprit behind your 20x slowdown.

Final Notes #

Always profile your code to confirm where the bottlenecks are! Tools like Visual Studio's Performance Profiler can show you if context switching, GC, or GPU contention is the main issue. And don't forget: even with the best scaling method, too many threads will kill performance—less is often more when it comes to parallelism.

内容的提问来源于stack exchange，提问作者Rick