Paint.NET v3.5.5 is now available

Here’s the final release for the update to Paint.NET that I’ve been talking about over the last few weeks. It brings performance improvements, a smaller download size, and of course the requisite bug fix. Thanks for everyone who has tried out the Beta and sent in bug reports and installation problems.

As usual, there are two ways to get it. The first is to just go to the Paint.NET website and download it; there is no need to uninstall your older version, as that will be taken care of automatically. The second way is to use the built-in updater. The program will automatically offer you the update within the new week, or you can go to the Utilities menu and click on Check for Updates.

Here’s what’s new since v3.5.4:

  • Fixed the bug where saving as 8-bit PNG/GIF/BMP wasn’t always working, usually with larger images.
  • Improved the performance of the Gaussian Blur effect by 30-40%.
  • Improved the performance of all the layer blending modes by 15-30%.
  • Improved the performance of zooming with the mouse wheel on dual-core Intel Atom systems.
  • Updated to support .NET 4.0 if no other version of .NET is installed.
  • Reduced download size from 4.8MB down to 3.5MB.
  • Fixed a small error in the Chinese translation.

Please note that Service Pack 3 (SP3) is now required for Windows XP users. For those using Windows Vista, you must now have Service Pack 1 (SP1) installed. If you do not have these installed, then the Paint.NET installer will open the appropriate download page on Microsoft’s site.



Paint.NET v3.5.5 and .NET v4 woes

image The transition to .NET v4 with Paint.NET v3.5.5 has not gone as smoothly as I expected. Right after I released the beta, I immediately started receiving reports of installation problems. Now, before I go into more details, I would like to assure everyone that nothing bad was actually happening. Systems weren’t corrupted, there was no data loss, etc. These weren’t even installation failures, per se; things just weren’t connected seamlessly like they were supposed to be. Clearly it wasn’t ready for prime time.

No, the problem was much more subtle than that and sadly didn’t show up in any of my testing. The reports were along the lines of, “.NET 4 installed and then Paint.NET didn’t do its own update.” If you then tried to run the Paint.NET installer again, nothing would happen: the extractor would run, you’d get a beep, and then nothing. After a reboot, however, you could then run the installer and everything would work great.

As it turns out, on Vista and Win7, .NET 4 first requires an update to some OS components (which it installs automatically). This update, like all other OS updates (e.g., via Windows Update), will not install if a reboot is already pending from another OS update. After that, .NET 4 can install itself. Then the final kicker is that you can’t run a .NET 4-based application until after another reboot. On “Patch Tuesday” it would be very common that TWO reboots would be needed. My installer simply can’t survive across a reboot, nor do I have a desire to implement the code to enable this. I certainly can’t add this code within the timeframe of a 0.0.1 update.

As Liz Lemon on 30 Rock would say, “Nerds!”


Let’s just go ahead and get it out of our systems: blah blah blah, reboots suck, what’re those Micro$oft morons* thinking, blah blah blah, Lunix wouldn’t do that because of course it’s perfect, blah blah blah. Now, let’s go back to being adults and just accept that this is the way it works, for better or worse. Please don’t spam the comments box with tirades about reboots. I don’t know why an OS update is necessary, but I sincerely doubt the .NET folks would have done this without a really good reason.

Anyway. This wasn’t the case for .NET 3.5 SP1: even if its installer reported that a reboot was necessary, it was still possible to run the Paint.NET setup wizard (which is a .NET 3.5 SP1 app) and defer the reboot until after everything was completed. More often than not, a reboot was not needed. I think I’ve only seen a reboot needed when installing on XP, mostly when Windows Installer 3.1 also had to be installed.

So, here’s the new plan for Paint.NET v3.5.5. It will not require .NET 4. It will still be based on .NET 3.5 SP1, but with a few important changes to pave the way for a hard dependency on .NET 4. If Paint.NET detects that a reboot is pending from a system update, then it will not auto-check for updates (clicking on Check for Updates will still work as normal). This will help to avoid the confusion when .NET 4 requires a reboot before it can install. I never implemented this before simply because it wasn’t necessary.

I still want to avoid end-user confusion related to .NET’s side-by-side nature. Unlike conventional wisdom might assume, .NET 4 does not include .NET 3.5 SP1 (or 3.0, 2.0, 1.1, and 1.0), which means many people would have installed .NET 4, uninstalled .NET 3.5 SP1 (why would you need it if you have the newer version, after all?), and then hit an error from Paint.NET saying that .NET 3.5 SP1 was required. This is exactly the same problem we had when .NET 2.0 came out and Paint.NET v2.5 still required you to install .NET 1.1. Back then I got more than a few grumpy and indignant e-mails and forum posts from people and calling me bad names because of this. It didn’t even matter that Paint.NET v2.6 was a few weeks away from release at the time.

In order to avoid this confusion, Paint.NET v3.5.5 will support running on a system which has .NET 4 but not .NET 3.5 SP1 installed. However, if both of them are installed then Paint.NET will use .NET 3.5 SP1. This keeps things much simpler for myself and, especially, for plugin authors. If you really do want to run Paint.NET v3.5.5 on top of .NET 4 (and let’s face it, we all want the latest shiny stuff), that will still be possible with a minor tweak to the PaintDotNet.exe.config file: just swap the order of the <supportedRuntime> elements so that the .NET 4 one comes first.

Paint.NET v3.5.5 will still be dropping support for XP SP2 and Vista RTM (pre-SP1). I was planning to do this anyway, as it’s an important stepping stone to phasing out XP support entirely for Paint.NET v4.0. It also helps to shrink the download size by about 700 KB because now I don’t have to include Windows Installer 3.1. Less bandwidth and more simplicity lets me focus on other things that are way cooler.

Going forward, have no fear. It will still be possible for Paint.NET to install .NET 4, then itself, and then not require a reboot until the very end. This involves finessing my setup wizard to target .NET 2.0, something you can always rely on nowadays. Which really isn’t as bad as it sounds; none of my planned changes require anything more than .NET 2.0 and I’d just have to rework some places where I use LINQ or whatever. The setup wizard uses some of the other Paint.NET DLLs but I can just inline that functionality. I’m certainly not rewriting my setup wizard to use WPF or TPL. It’s just something that can’t be done without more code churn and a longer beta testing period.

Expect to see a new beta release shortly.

* I work for Microsoft too, by the way.

How to: Target .NET 4.0 Client Profile with C++/CLI

While porting Paint.NET v3.5.5 to .NET 4, I naturally ran head-first into the problem of making sure my two C++/CLI assemblies were targeting the client profile and not requiring the full framework. The problem here is that Visual Studio 2010 does not have a UI for setting a C++/CLI assembly’s target framework version and profile.

On MSDN, I found that someone had added a note on how to target a non-v4 version of the framework by editing or adding a <TargetFrameworkVersion> element to the VCXPROJ file. Once I saw this, I looked as the CSPROJ files for my other assemblies to see how they did it, and they were using the same element with the same value in the same location. They also used an additional element to specify which profile (Client or Full) was targeted. On a whim, I decided to guess and check to see if this same element was honored by the C++/CLI compiler, and it is!

So here we go: (this is modified from the text already at the page linked to above)

To change the version and profile of the .NET Framework for C++/CLI projects (VS 2010)

1. Right click on project in Solution Explorer and click Unload project
2. Right click on unloaded project in Solution Explorer and select Edit <projectname>.vcxproj
3. In project XML file locate node <PropertyGroup Label=”Globals”>
4. In that node locate node <TargetFrameworkVersion> (if the node cannot be found, add it)
5. Inner text of the node defines target framework. It can be v2.0,v3.0, v3.5 or v4.0
6. In that node locate node <TargetFrameworkProfile> (if the node cannot be found, add it)
7. Inner text of the node defines the target framework profile. For the Client profile, set it to Client (for Full, just omit the element)
8. Save vcxproj file and close it
9. Right click on unloaded project in Solution Explorer and click Reload Project


<PropertyGroup Label="Globals">     

Paint.NET v3.5.5 Beta … now with .NET v4!

Edit: Updated forum link. Also, this build is now available via the built-in auto-updater!

Visual Studio 2010 and .NET v4 are out! As usual, Scott Hanselman has some good coverage on this so I won’t repeat what he’s already published.

Anyway. Back in January, I announced that Paint.NET would be removing support for XP SP2 and Vista RTM “later this year.” Well, that time has come! From now on, Paint.NET will require XP SP3 or Vista SP1 (or Windows 7 of course). This is a result of migrating to .NET v4. I’ve spent the last few hours upgrading Paint.NET v3.5.5 to Visual Studio 2010 and .NET v4, along with a small army of fixes and changes that come with any big upgrade like this.

So, if you’d like to try out the first version of Paint.NET ported to use the brand spankin’ new .NET v4 …

… then head over to the forum and download it!

Please note that there are no .NET v4 specific changes or upgrades to Paint.NET. None. Please don’t ask me if it’s using System.Threading.Tasks, or Windows Workflow, etc. The answer’s no 🙂 Paint.NET will of course benefit from all of the regular optimizations that are in .NET v4, and this is also serving to pave the road for Paint.NET v4 to have a more seamless upgrade path. It also helps to unify my development setup so that I won’t need two copies of Visual Studio installed. Lastly, it helps to avoid a lot of confusion since otherwise installing .NET v4 would not enable you to install Paint.NET v3.5.4; it would still bark at you to install .NET 3.5 SP1. This is due to .NET’s side-by-side versioning system (which is actually a very good thing).

March 2010 usage statistics

Here we go again! Last month I published some great numbers showing big gains in the areas of Windows 7, 64-bit, and Russian. This month there really isn’t much to report. Paint.NET usage is up a little, by about 4.3%. Windows 7 has cracked the 20% mark but that isn’t much of a jump since last month. Vista and XP have dropped a little, and 64-bit is showing a small gain (+6.7%). All in all a pretty quiet month, but things are still going in the right direction. (Please upgrade to Windows 7!)

Coding work on Paint.NET v4.0 has been progressing steadily, with a lot of progress being made on what you could call technology upgrades. More importantly I’ve made it past some important decisions. XP support is out so that I can focus on Win7/Vista and use Direct2D, DirectWrite, and the latest WIC (Windows Imaging Component) improvements. I’m hoping to implement a ribbon, although I’m still not entirely sure how to approach MDI with it. I think the current tabs+thumbnails approach works very well, but it may conflict with the official Ribbon UI licensing requirements. The canvas area will be hardware accelerated as much as is possible, and I’m also planning to pull in a docking panels system for the tool windows. Honestly, the transparent floaty windows thing was a neat idea but is starting to show its age, and it doesn’t work well at all on netbooks (1024×600 is a common resolution), or for a non-maximized window. The result is a very cramped UI for many situations. The library I’ve chosen to handle this works very similarly to Visual Studio, and has a lot of happy users already.

Here are some ugly pie charts:

And lastly, here are the raw numbers. Please note that “hits” refers to update manifest text files, not web site traffic in a browser. They are the result of an installation of Paint.NET being active and checking to see what the latest version is. Paint.NET doesn’t check for updates unless it’s open (no TSR’s), and it checks every 5 days at most (longer if it hasn’t been opened in more than 5 days, of course). Thus, these numbers are closer to indicating usage of Paint.NET as opposed to the raw, installed base of users.

February 2010 March 2010
Total update manifest hits 3,922,732 4,528,824
Hits per day 140,097 146,091
32-bit 87.72% 86.89%
64-bit 12.28% 13.11%
Windows XP 56.43% 55.76%
Windows 2003 0.24% 0.24%
Windows Vista / 2008 25.02% 23.72%
Windows 7 / 2008 R2 18.31% 20.29%
English 38.86% 38.85%
non-English 61.14% 61.15%
German 15.34% 14.68%
French 7.76% 7.79%
Portuguese 4.85% 5.20%
Spanish 5.90% 6.02%
Japanese 2.24% 2.24%
Italian 3.56% 3.57%
Polish 1.54% 1.51%
Netherlands (Dutch) 1.37% 1.35%
Russian 9.48% 9.79%
Chinese (Simplified) 0.67% 0.75%
Chinese (Traditional) 0.46% 0.55%
Turkish 3.68% 3.49%
Korean 0.31% 0.35%
All other languages 0.93% 0.81%
Have translations 79.48% 79.45%
Don’t have translations 20.52% 20.55%

Bold indicates that Paint.NET ships with the translation. Korean had a translation in v3.36, but not in v3.5+. For Russian, the reverse is true.

The Paint.NET forum has moved! Yay!

image When I mentioned that the forums were down for most of last week, I also promised it’d be worth it: we have finally moved the forum so that it’s sitting on our own hosting and not on freebie hosting. We’ve also migrated to IPB from phpBB, and will be adding and enabling more great features over the coming days and weeks.

Sorry to keep everyone in the dark, but we had to keep everyone in the dark, including our old freebie forum hosting provider.

The new address is

As with any large exodus or migration, there will be some glitches. For instance, apparently everybody on the forum was born on January 1st, 1970 🙂

Over time I’ll try to make sure all the links on this blog are pointing at the new location.

One nice thing about a big leap like this is that we can shed some dead weight. I just deleted over 16,000 accounts which had zero posts: that’s more than half the entire list of users!

Direct2D and WinForms: It Just Works

About a month ago I ported the Curves adjustment UI to use Direct2D for the transfer map (the interactive spline/grid). This meant that a rectangular portion of the form was carved out for Direct2D. If you’ve used WPF interop then you’ll be familiar with “airspace limitations”, and I was curious as to whether it would be possible to put a WinForms button on top of an area that is being rendered to with Direct2D. In other words, if you use Direct2D to render to an area of a Form, does it completely take over that rectangular area?


Now, you can always take a guess, “Well of course you could/couldn’t do that because of explanation involving logical deduction or other example setting precedent.” For engineering purposes, however, something like this must be shown to work before taking a dependency on it.

And what do you know, it does work:


This screenshot shows a Form that contains a single control of type “D2DThingy.” That control then has 5 children controls of various types, and they are all stock WinForms controls. Clearly, they are able to coexist peacefully and without artifacts like clipping or flickering. Like with any WinForms UI there is still a lot of work to make sure that the background of the Button matches up with what’s behind it, etc. but that is a known problem with known solutions.

This is of special importance to me because I want to write a new toolbar UI for Paint.NET v4.0. However, I absolutely do not want to write my own ComboBox or TextBox controls. I could spend a full 12 months on a globalized TextBox that can work with all languages, input types, etc. Thankfully I won’t have to.

Try out Paint.NET v3.5.5 Beta

The forum has been down for most of this week. So, to reward (?) everyone’s patience and understanding I have posted a public beta for Paint.NET v3.5.5 which I blogged about earlier. Things will be back up soon, and I promise it will be worth the wait.

This isn’t available via the built-in updater, and the installer isn’t even digitally signed. It’s a beta and has not been fully tested, so all the usual warnings and scare tactics apply. I’d really like to get everyone’s feedback on the performance improvements 🙂 If they all work out then I’ll make sure more of them get into future releases.

What’s new:

  • Fixed the bug where saving as 8-bit PNG/GIF/BMP wasn’t always working. This often happened when “Auto” bit-depth was selected, and based on the color complexity of the image it would choose 8-bit (for a smaller file-size) and then fail with “error”. Usually this only happened with larger images. This was discussed here on the forum at
  • Improved performance of Gaussian Blur by 30-40% depending on your CPU (Intel Core i7 seems to show the best improvement).
  • Improved performance of all the layer blend modes by 15-30%, depending on your CPU (Intel Atom seems to show the best improvement).
  • Improved performance of zooming with the mouse wheel on dual-core Intel Atom systems.

The download link is over at the forum.

Also, do note that while I say that either of those two Intel chips (i7 or Atom) shows the best improvement, please keep in mind that I haven’t yet benchmarked on any other CPUs (Core 2, Phenom, etc.). I just picked up the new Intel Core i7-980X and it screams (especially at 4 GHz!). Paint.NET is faster than ever, and thankfully so are my build times for Paint.NET v4.0.