TLDR: Get DirectBitmap from https://stackoverflow.com/a/34801225 and add ```csharp public void SetPixel(int x, int y, int argb) { int index = x + (y * Width); Bits[index] = argb; } ``` then change GetStaticNoise to ```csharp readonly static int white = Color.White.ToArgb(); readonly static int black = Color.Black.ToArgb(); readonly static Random NoiseRnd = new Random(); private static DirectBitmap GetStaticNoise(int width, int height) { var bitmap = new DirectBitmap(width, height); for (int y = 0; y < height; y++) { for (int x = 0; x < width; x++) { var rnd = NoiseRnd.Next(0, 2); bitmap.SetPixel(x, y, rnd % 2 == 0 ? white : black); } } return bitmap; } ``` Long story: I have done stupid things in the past and know how to optimize your code To start with, there is no need to guess when you can just ask code profiler to tell why your code is slow :) Roughly 96% of CPU time is spent in ```GetStaticNoise``` in which major culprit is, unsurprisingly, ```SetPixel```. [![code profile of GetStaticNoise][1]][1] Before dealing with big fat pixel setting, lets take a look at other lines with surprisingly high CPU time. - bitmap.Width and bitmap.Height does [bunch of stuff][2] under the hood. - [preset colors isn't a simple integer][3], but a fat object. - Random.Shared creates Random object for each call. It is also thread-safe, which means there will be some performance cost hidden inside - Ternary conditional operator generates different bytecode than full IF, and can be faster for conditional assignments Few seconds of refactor later you get about +10% performance for "free". [![itsy bitsy refactor][4]][4] You could optimize further by reusing Bitmap, but for that size would have to be either constant or hook into ```OnSizeChanged``` event. Knowing that ```SetPixel``` is a performance hog, you can just search for "c# fast SetPixel" and just copy&paste [ready to use solution from another SE post][5]. Make sure to read through the comments on why it is not a perfect solution. Lo and behold, performance increased tenfold just by not using [SetPixel unnecessary safety logic][6]. But that ain't the end, let's run profiler again to get reminded that ```Color``` object sucks for game development. [![ugh this damn Color object...][7]][7] With color already being prefetched, we can preconvert it as well and suddenly code is so fast that property getter becomes performance hog, taking whole 5%! [![surprising performance hog][8]][8] Chopping properties away you can reach spot where Random numbers takes longer to generate than SetPixel. [![diminishing returns][9]][9] But at this point we have pretty much reached limits of software rendering on windows desktop. For faster performance you'll need to use GPU. [1]: https://i.sstatic.net/MazZg.png [2]: https://github.com/dotnet/winforms/blob/092d2d7d1845f538cbe198d9f624b82c1027d2a1/src/System.Drawing.Common/src/System/Drawing/Image.cs#L532 [3]: https://github.com/dotnet/runtime/blob/57085686bf7223e2305720383f4e00695321919a/src/libraries/System.Drawing.Primitives/src/System/Drawing/Color.cs#L40 [4]: https://i.sstatic.net/L5WqW.png [5]: https://stackoverflow.com/a/34801225 [6]: https://github.com/dotnet/winforms/blob/092d2d7d1845f538cbe198d9f624b82c1027d2a1/src/System.Drawing.Common/src/System/Drawing/Bitmap.cs#L319 [7]: https://i.sstatic.net/vZwDY.png [8]: https://i.sstatic.net/aKs9b.png [9]: https://i.sstatic.net/yRtb5.png