Paint.NET shows up on Maximum PC July 2007 cover disc

An intrepid forum member, “startreksuite,” pointed out that Paint.NET is on the latest cover disc. This was, as usual, news to me! So I stopped by Best Buy with a friend earlier today and after nerding out on all the video games and movie DVD’s and high-def TV’s, I found the issue and lo and behold, on the back of the issue …

Heck yes, very cool! It looks like they included version 3.05, so most of those who install will quickly get an invitation to upgrade to 3.08. Wow, I spent $9 on this thing! I wonder when they’ll start e-mailing me about these things 😉

I was going to pick up the PC World with Paint.NET in it, but they only had the June issue. I don’t think it’s set to make an appearance until the July issue, which should of course be any day now.

Paint.NET versioning: Why is it version “3.08,” instead of “3.0.8” ?

Sometimes I see news and update sites listing the latest release of Paint.NET with three version fields: 2.7.2 or 3.0.8, for instance.

It’s actually 3.8 if you look at the version resource in Windows.

In truth, 3.08 really is more of a “3.0.8” release: it’s mostly the same as 3.0, except with bug fixes and minor changes that don’t radically change the user experience. Sure, 3.05 added a new effect and 3.07 added on to the Line/Curve tool. But whatever. In truth, I’d prefer to have called these last releases 3.0.1 through 3.0.8. So why didn’t I?

There are really two questions to answer:

  • Why does the version resource say 3.8 instead of 3.08?
    The reason is simply that you can’t actually express “3.08” in the version resource. It isn’t one number with digits past the decimal place, it’s four separate integers. I had to write custom code in Paint.NET so that “3.8” was printed out as “3.08.” Each number in the version can have a value from 0 to 65535, inclusive. So you can have all the way up to 65535.65535.65535.65535. But if you try to specify “1.01” then the “01” just parses to 1 and you’ll get “1.1.”
  • Why isn’t it 3.0.8 then?
    You get four numbers, or fields, for your version. The fields are for the major version, minor version, build number, and revision. The build number and revision number are auto-generated based on the date and time: the build is the number of days since January 1st, 2000, and the revision is the number of seconds since midnight divided by 2. I think it uses UTC time – it doesn’t seem to reset to zero at midnight local time for me J The build number incrementing daily is very useful, and I don’t wish to override that behavior. So, I simply use the minor version field and use custom version printing code in the UI.

    (And yes, I could have the UI print it as “3.0.8” but then it just gets messy if you want to present the full version string: Wow, that’s a lot of numbers!)

You might think this could become confusing for users, but really it’s probably more confusing for me! Versioning is really about sending a message, or branding if you will. If an update is just a bugfix release, then I’ll increment the version by “0.01,” announce it as such, and that’s what users will see. If I’m adding features and / or significant UI tweaks, then that’s worth a few more version points. If I were to release “3.1” through “3.9” and then skip to “3.10,” then not only would users be expecting major improvements along the way (while not getting them!) but they would probably expect 4.0 to follow 3.9. “Yay, 4.0 is almost here! …. Aww lame. All we got was 3.10, I feel cheated.”

In the past, Paint.NET had a new version every few months. Lately I’ve been trying to get updates out every 4 to 6 weeks. I think it’s working pretty well: users get bug fixes and small features sooner, and the project gets a lot of recurring attention from outside of the “Beta crowd.” However, it’s about time to get back to working on a larger release, so I think I will cut down on the micro-updates for awhile.

May 2007 usage statistics for Paint.NET: Vista usage way up!

As many of you know, Paint.NET has a built-in updater. Every once in awhile*, it will ping the website to see if there’s a newer version available, and if so it will invite the user to install it. Two clicks of the mouse later and the user now has the latest version. From the server’s perspective, the implementation is very simple: the client just asks for a text file, and that text file is delivered via standard HTTP mechanisms. This text file is called an update manifest, and basically just includes a list of URL’s for the latest stable and beta releases. The filename is built from the following information: manifest schema revision (currently “5”), client Windows OS version and bitness (x86 or x64), and system locale. This gives me the ability to target updates to specific versions of Windows, and to specific languages. For example, when v3.0 was released I was able to make sure that Windows 2000 users were not offered an update that they could not install (“how rude!”).

It also lets me gather simple, anonymous usage statistics.** These numbers don’t give me installation numbers, but rather they give me rough usage data: if someone uses Paint.NET a lot, then they will ping their appropriate update manifest up to 6 times in one month. This is much more valuable to me than raw installation numbers, and definitely much more valuable than website viewing statistics (yes, some people still use Windows 95).

I’m going to perform an experiment here and publish this data. Right here, right in this blog post! I’ll monitor the reaction and go from there.

In total, the update manifest files were downloaded 943,360 times during the month of May. Since the manifest files are usually about 500 bytes, the bandwidth usage is boring. So, let’s break it down by OS and then by locale:

Paint.NET usage by OS










Windows XP



Windows Server 2003



Windows Vista



No surprise that most people are still using good ol’ 32-bit Windows XP. However, it’s very surprising to see that over 10% of Paint.NET users are already on Windows Vista! I personally consider that to be a good thing. Heck, I like Vista. Remembering back to the statistics from about 1 year ago, 64-bit has not made large strides yet, and is still hovering at about 1%. Windows 2000 is not included because Paint.NET v3.0 and newer require Windows XP SP2 or newer. There are even a few people using Paint.NET on their Windows Server boxes.

Paint.NET usage by locale
One of the big pushes for Paint.NET v3.0 was to include translations for languages other than English or German, and boy has that paid off.

Edit: Please note that these numbers indicate what locale Paint.NET is set to, which defaults to the system’s setting. If a translation for the locale is not available, then the user interface will be displayed in English. These numbers do not directly indicate what language Paint.NET is being displayed in. For example, Italian is listed at 2.27% — now, there is an Italian translation available on the forum. But this 2.27% just means that the absolute upper bound for users that have the translation downloaded and installed is 2.27%. The rest have the UI shown in English. For my purposes of analysis, I assume that nobody has downloaded the language packs from the forum (“worst case scenario” analysis makes things that much more dramatic J). I hope this makes things clearer.






















Netherlands (Dutch)






Chinese (Simplified)






Chinese (Traditional)









The rest



Have translations



Don’t have translation



If a row is green, that means Paint.NET ships with a translation for that language/locale. Red means it doesn’t . We’ve got the top 6 locales covered, which is great! Translation coverage has increased from 63% up to 87%***. It looks like our biggest weak spots are translations for Italian, Dutch (Netherlands), Russian, and Polish.

Remember, these numbers only indicate usage for Paint.NET, and only for those clients which have the updater turned on. For instance, I’m not trying to claim that 10% of all Windows users have already upgraded to Vista. Also, there was a server configuration issue that prevented Polish users from being able to download the updater files. The server was trying to load the files as Perl scripts or something. Thankfully, some members on the forum were persistent and it led to an easy fix, albeit half way through the month (May 14th). This means that the numbers above for Polish are way lower than they should be.

So, what do you think? Are these statistics interesting? Should I publish these monthly, yearly, never? More analysis, less analysis? Pie charts? More cowbell?

* Up to once every five days.
** Yes, really and honestly anonymous. I don’t have any IP addresses or host names. I don’t even have access to the actual log files, I just have some stats package on the web server that I have to fumble around in. Privacy was an important consideration when designing and implementing this stuff.
*** Paint.NET 2.5 through 2.72 only had English and German, and 46.49% + 17.25% = 63.74%

What’s next for Paint.NET?

So version 3.08 is fresh out the door, which means it’s time to start on the next release! The last few releases since v3.0 have mostly been servicing releases (aka “bugfix releases”), with a few features and refinements thrown in for good measure. Service releases are important in order to fix top pain points for users, but it’s also great when some new features are introduced too (even if just a trickle). Not everyone is affected by every bug, so why force everyone to download the fix for it? If I add a trickle of new features or refinements, then everyone is able to benefit from even a +0.01 update. And then I get to go drink beer! It’s a win-win-win scenario.

Anyway, I’m currently planning out the next two major releases: “3.Next” and 4.0.

“3.Next” might end up being named 3.20, and that’s how it’s described on the Roadmap page. The big area I want to focus on in this release is the experience around plugins, for both the user and the developer. I will be creating a new, richer plug-in API (and adapters for old plugins, don’t worry!). The user interface will allow you to install these plugins right from within the application, and to enable / disable them individually without having to muck around in the file system. Users have also been crying out for a way to organize their effects into submenus, and I’m hoping to provide that as well. You’ll also be able to install a plugin just for yourself, or for all users on the system. Maybe I can also provide a way for plugins to be able to check for their own updates and to then invite the user to install them (like Firefox does). I also want to make it much much easier to write UI for Effect plugins. Right now it is a very clumsy experience.

Along with the plugin management, I think it’ll also be very useful for Paint.NET to allow you to configure the file types that it is registered to handle. Right now you essentially have to re-install Paint.NET to get to these options. Granted, these aren’t options that you really need to touch very often, but when you add file type plugins it’s another ballgame: if you install the DDS plugin, how great would it be for Paint.NET to be able to register itself to handle *.DDS? Right now these file type plugins are on their own, and it sucks for the user.

As you may be guessing, this means that “3.Next” will have a Configuration dialog (aka Options, Settings, Preferences, etc.). I have always been fiercely against providing a dialog like this in Paint.NET because they can easily degrade into a buffet of confusing checkboxes, radio buttons, and all sorts of propeller-head idiocy. Sometimes you end up needing a large supplementary manual just for this portion of the user interface. I recommend that you read Jeff Atwood’s Coding Horror blog post from last November, “This Is What Happens When You Let Developers Create UI“. It’s a good read J

The Configuration dialog in “3.Next” will only provide options that really matter. There will not, for example, be a “Tile Cache Size” option, or anything else that requires 3 pages of text to explain. Those are things that the application should be able to optimize itself, and that the user shouldn’t need to give a damn about. The Tool->Choose Defaults and the updater options will also be consolidated here.

Version 4.00 is going to be a whole new ballgame, and is also discussed briefly on the Roadmap page. There are certain areas of Paint.NET that, quite honestly, only work because they have been thoroughly debugged. I have identified three areas that are in need of major overhauls: the data model, the application model, and the image rendering engine. So basically the entire program (oops).

The data model needs to be more resilient to nested actions. Right now the application is given direct access to the data and expected to “do the right thing.” That sort of trust never scales over time, not even on a relatively small project like Paint.NET. I want to move to a more transaction-oriented system, with support for nested and ambient transactions.

The rendering engine right now is pretty simple in Paint.NET, consisting of methods called Render() that are given a target and a region of interest. This works great for linear composition, but nested composition is out of the picture. What if I want to attach a mask or an adjustment to a layer? I can’t do that right now because I don’t have a 3rd rendering buffer, nor do I want to require the memory it takes to do that. So this means the rendering engine must move to working with tiles instead of whole bitmaps (yes, just like every other non-Paint editor out there J). Tiles are generally light weight and can be cached, copied, paged out to disk, paged in to memory, etc.

The application model needs to be refactored so that it separates front-end (user interface) from back-end (logic). This and the data model changes are tightly intertwined, and will provide the foundation for such features as scripting and automation.

That’s enough writing for now. Hopefully this gives some good insight into the direction that Paint.NET is going, both short-term and long-term.