Download Paint.NET Download Free – 5.10 Beta Build 8980

Developed jointly by Washington State University with additional assistance from Microsoft, Paint.NET is intended to be a free replacement for the MS Paint software that comes with all Windows operating systems. Paint.NET is an image editing and manipulation software.

Download notes: Alternatively, you can download the latest stable version of this software.

The programming language used to create Paint.NET is C#, with GDI+ extensions.

Paint.NET has many of the powerful features that expensive commercial applications have, including the ability to use layers.

This is the second semester Paint.NET has been a project at Washington State University, and we aim to add as much functionality as expensive commercial applications provide, but of course for free.

In the spirit of all this freedom, we welcome all suggestions, as well as providing the source code for free to anyone who wants to tinker with it.

What is new

Quite a lot has changed since the last alpha release (build 8930). I wasn’t planning on a month and a half long gap between builds, and I was actually hoping to be close to the final/stable release by now, but everything I’ve learned about color management and the Windows build to support it led me to some important course corrections. I also implemented some pretty dramatic memory usage and performance improvements.

Here’s a quick summary of what’s new/changed for the beta compared to the alpha:

• Massive reductions in memory usage when working with multiple images
• Greatly improved canvas framerate for lower-end and integrated GPUs (eg Intel UHD/Iris/Xe, AMD Radeon Mobile)
• Color management for the screen is now handled by Windows via Advanced Color and Automatic Color Management

Massively reduced memory usage

I’ve wanted to do this optimization for a while, but it was a very technically challenging problem and I was never able to make enough progress on it (while keeping the app stable and reliable, mind you).

Fortunately, some new pieces of the puzzle recently fell into place, making this a very easy problem to solve. I’m happy to report that GPU memory usage when working with multiple images has been greatly reduced. See below in the fine print for technical details.

Additionally, earlier in 5.1’s development I implemented an optimization that greatly reduced CPU memory usage by up to half. This was done by moving canvas tiles to the GPU instead of copying them. Tiles can easily be recreated, so why have them on the CPU? The only real downside is that toggling certain settings, namely “Enable Hardware Acceleration” and “Windows Advanced Color,” will result in a brief flickering of the canvas and other UI elements.

The savings are really quite dramatic and should smooth things out a lot for many. Let’s explore this with some data from 2 scenarios that I tested. For both of these tests, I launched Paint.NET, maximized the window on my 4K monitor, and then opened a series of images. Memory usage figures were obtained from the Task Manager.

In the first test, I opened up 50 images that are 6 MP (megapixels) in size (3000 x 2000 pixels). In PDN 5.0.13, memory usage was 2,527,960 KB on the CPU and 5,818,172 KB on the GPU (about 2.5 GB and 5.8 GB, respectively). In 5.1 Beta, it’s down to 1,402,148 KB on CPU and 2,427,332 KB on GPU (about 1.40 GB and 2.43 GB, respectively). So that’s about a 50% reduction overall.

This one is more contrived, at least in my opinion, but it shows how much better things are in a more extreme scenario. For this I opened 200 very small images between 16×16 and 64×64 pixels (various icons from the PDN UI). In PDN 5.0.13, the memory usage was 356,772 KB on the CPU and 12,431,560 KB on the GPU (which is about 12.43 gigabytes). In the 5.1 Beta, CPU memory usage was down slightly to 335,044 KB while GPU memory usage was reduced by over 97% to just 281,188 KB.

So depending on how many images you open, and how big they are, you can easily see PDN using 50% less memory on both CPU and GPU. Things will be faster and more stable as a result. Enjoy.

Greatly improved canvas frame

I’ll admit that I was a bit worried about PDN 5.1’s performance during alpha. It worked just fine on my desktop PC, but it has a top-of-the-line processor and GPU, so it’s no feat. On my laptops and other test systems, which mostly have Intel iGPUs, I couldn’t come close to the level of PDN 5.0’s performance. The canvas was still running at 30+ FPS, so it was still well within what they call “interaction-grade” performance, but it lacked the refined smoothness that it really should have.

After some deep performance research and a complete rethink and re-engineering of how the canvas is rendered, I’m happy to report that this is completely fixed! Framerates on typical integrated GPUs (which power nearly all laptops) are now solidly in the 60+ FPS range. I’ve also been able to improve performance when hardware acceleration isn’t enabled, which should help on systems with very old GPUs that don’t support DirectX 11, or when running the app in a virtual machine or other shared environment where a GPU isn’t available.

The irony is that this performance improvement was mostly done by reducing the involvement of the GPU. Paint.NET’s color processing is now mostly done on the CPU in the background as part of layer compositing and mipmap production. Completed tiles are now sent to the GPU in a “presentation ready” format (FP16, scRGB color space). Previously, tiles were passed using the linearized color space from the image, and this required additional color space transformations on the GPU while rendering the canvas. They are now gone, and in their place is a nice framerate boost and a reduction in power consumption. Scrolling and zooming are much better now.

Screen color management is now handled by Windows

In the alpha there was a checkbox in Settings -> Color Management that was labeled “Use monitor’s color profile.” To use this you had to be using an SDR monitor (which most are these days) and you needed a color profile for your monitor and you had to have installed that color profile using the super confusing color management control panel.

I left this setting disabled by default because I didn’t think many people would be able to take advantage of it properly (not without a lot of work anyway) and enabling it by default would have caused many people thought that the color in Paint.NET was now “broken”. In addition, the code to handle all of this was complex and fragile, and would be difficult and expensive to maintain going forward.

The second checkbox in Settings -> Color Management, “Windows Advanced Color,” is applied to monitors configured for High Dynamic Range (HDR) or Wide Color Gamut (WCG) mode. In this mode, Windows automatically manages colors relative to the display using the color space information provided via the EDID. You don’t need to install a color profile or deal with the old Windows Color Management control panel.

The “Use monitor’s color profile” setting is now gone, and only “Windows Advanced Color” (enabled by default). This means that color management for the screen in Paint.NET is handled exclusively by Windows, and is only dependent on having configured the screen for either High Dynamic Range (HDR) or Wide Color Gamut (WCG) mode. I expect HDR and/or WCG to gradually become the mainstream configuration, leaving SDR as a historical relic (eventually), so it didn’t make sense to me to keep the complicated “Use monitor color profile” code given the projected costs of maintain it. I had to rip it out eventually anyway, so why send it at all?

Many people know what HDR is, and in Windows it has a reputation for being quirky and buggy. Complaints of “washed out colors” are common when enabling HDR, and this is actually a complicated and difficult color calibration issue. HDR mode works really well… if your PC manufacturer calibrates and configures things correctly, or if you spend hours fiddling with the color settings on your screen. My Lenovo P16 laptop works great in this mode, but every other system and monitor I have has major issues with it.

WCG hasn’t gotten much attention (yet?) and doesn’t seem to have the problems that HDR mode has. WCG is actually a new variant of SDR mode introduced in Windows 11 (you can also use it on HDR displays). In WCG mode, Windows will use 10-bit output (or 8-bit with rasterization) and enable automatic color processing just like in HDR mode.

As of Windows 11 v24H2, most SDR displays can use WCG mode as long as the GPU is modern enough (see here for requirements). You can think of WCG in two ways: it’s either HDR without the extended brightness range and bugginess, or it’s like SDR mode, but with high bit depth output, Automatic Color Management and access to the screen’s full color gamut (full range of colors) (btw , SDR mode is always limited to 8-bit output, regardless of any settings in the GPU’s vendor-specific control panel).

Changes since 5.1 alpha build 8930:

• Improved: GPU memory usage when working with multiple images has been greatly reduced
• Greatly improved performance (framerate) for the canvas on integrated and lower GPUs
• Removed: Settings -> Color management -> “Use monitor’s color profile.” Color management with respect to the display is now handled exclusively by Windows and requires a display configured for High Dynamic Range (HDR) or Wide Color Gamut (WCG).
• Improved: Windows Advanced Color is now used for the Colors and Layers window, as well as for thumbnails at the top of the main window. They are no longer limited to sRGB and can display the full range of colors defined by each image’s built-in color profile.
• New: Effects -> Rendering -> Clouds now has a tab to configure the colors used for rendering