As most people know, Paint.NET started as a senior design project at Washington State University’s EECS department. When we finished the first version, it was meant as a “hey look we actually made something - neat!” project that we showed off to family and friends. A simple website was put up on the eecs.wsu.edu web server, and the project was neither hyped nor advertised once the semester was over. Fast forward a few months later, after I started working full time at Microsoft, and I was forwarded e-mail from some interns who had managed to find it and were asking about why it wouldn’t install on XP SP2.

Interesting things to know about the first version of Paint.NET, in no particular order:

· It took 15 weeks to complete, from start to finish.
· It was about 36,000 lines of code.
· It was distributed as a raw MSI, instead of an installer/wizard EXE.
· It required Windows XP SP1 as the minimum OS. There was no support for 2000.
· And, because of a typo, it did not work in Windows XP SP2! Changing an equals operator, =, to a greater-than-or-equals operator, >=, fixed this.
· Plugins were not supported.
· We used a CVS server that was running on an XP box that doubled as one of our development workstations. It was in the EECS computer lab that other people had access to, and we had to tape a piece of paper on to it that said, “SERVER - DO NOT TURN OFF!”
· We did not have a bug tracking system. We either fixed bugs immediately as we saw them, or put them in to an Excel spreadsheet (mostly the former).
· I made the floating windows translucent after observing that most people didn’t even try drawing in the occluded areas when I handed them a tablet PC with Paint.NET on it (”hey you, draw something!”). It was if that area of the canvas didn’t exist. Once the windows were made translucent, this went away! Usability studies really do work.
· For the first month or so of development, the status bar had no information in it. Instead, it had the text: “I am the status bar!!!!!!!!!1111″

Changes since v3.30:

* New: Enabled integration with Window Clippings, which is a high quality screen capture utility by Kenny Kerr.
* Fixed: Fixed a crash with the Open/Save dialogs if the Documents or Pictures directories were either inaccessible or if the user did not have certain file system permissions.
* Changed / Fixed: The hotkey for Adjustments -> Levels is now Ctrl+Shift+L instead of Ctrl+Alt+L. This was preventing certain characters, such as the Polish ‘ł’, from being typed.

For this update I’ve also worked with Kenny Kerr to enable integration between Paint.NET and his Window Clippings utility. It now has a built-in “Send to Paint.NET” action so that when you take a screenshot it will automatically send it to Paint.NET without a filename (”Untitled”). Before, this had to be done manually and it was a bit clumsy because it would show up in the File -> Open Recent menu with a long, computer generated file name. It was also tricky to ensure that the alpha channel, which Window Clippings captures correctly for Vista/Aero effects, made the trip correctly.

To kick this off, we also have a special deal — for the month of May we’re knocking $4 USD off the price of Window Clippings for Paint.NET users! Now it’s only $14 USD instead of $18 USD.

You will also see this offer when you install Paint.NET v3.31. I use this program myself, and it saves me a ton of time when I make screenshots, e.g. for the Paint.NET help and documentation. I really like how it automatically captures all of the Vista/Aero effects, such as the transparency and the drop shadow. I highly recommend it.

In other news, the weather here in Kirkland is great* and I’ve got the week off. I can finally reliably finish Green Grass and High Tides in Rock Band on Expert (4 stars), and Grand Theft Auto IV comes out tomorrow.

* Well, for now … who knows what tomorrow will be like!

The Official Paint.NET Merchandise store: http://www.cafepress.com/paintdotnet/

There are shirts, a mouse pad, mugs, stickers, buttons, hats, and a tote bag. If you have feedback on the selection, either leave a comment or join the discussion on the forum here: http://paintdotnet.forumer.com/viewtopic.php?f=12&t=24051

Over the next week I’ll add links to the store added in other places, such as the main website. For now I’ve got the link here on the blog and on the forum. Cafepress doesn’t leave much room for profit, so this is mostly a promotional tool. Which means that if your intent is to send $20 to Paint.NET then we’re both better off if you donate directly. Purchasing a $19.99 shirt via Cafepress only nets me $1 or $2. If you want a shirt, then by all means buy one – but if you want to donate, then just donate

I’m not sure why I didn’t do this two years ago, it was rather easy to set up and the response so far has been very positive.

Enjoy!

Changes since v3.22:

• New: Italian translation.
• New: Ability to save PNG’s at 8- and 24-bit color depths.
• New: Ability to save BMP’s at 8-bit color depth.
• New: "Auto-detect" bit-depth option for PNG, BMP, and TGA file types. It will analyze the image and determine the lowest bit-depth that can still save the image without quality loss.
• New: "Fragment" blur effect, by Ed Harvey
• New: The "Polar Inversion" distortion effect has been enhanced to allow changing the rendering offset, and the behavior for "edge" pixels (clamp, reflect, or wrap).
• New: For developers, added a Color Wheel control to IndirectUI for use in effect plugins.
• New: For developers, added ability to customize certain properties of the effect configuration dialog via IndirectUI.
• New: For developers, IndirectUI can now be used to write configuration UI for file types.
• New: For developers, IndirectUI has a new radio button control type for enumerations, and some new property constraint rules.
• Changed: Most effects and adjustments, including plugins that use IndirectUI, have been visually refreshed. The new look is cleaner and more compact. These changes are shown in more detail at http://blog.getpaint.net/2008/03/10/cleaning-up-the-ui-for-paintnet-v330/
• Fixed: Various UI issues with the Levels adjustment.
• Fixed: When pasting text into the Text tool with Ctrl+V, it would hide the nub for moving the text.
• Fixed: If the startup tool was set to the Zoom or Pan (Hand) tool, then the toolbar would render incorrectly.
• Fixed: Thumbnails for PDN images now include transparency, which improves their appearance in Windows Vista.
• Fixed: In some cases, an exponential property slider would get "stuck" at some values when using up/down keyboard keys. This mostly affects some effect plugins.
• Fixed: When using keyboard navigation, sometimes the File menu would scroll its items out of view.
• Fixed: Some crashes that were tracked down to out-of-bounds coordinate values in certain effects.
• Fixed: The installer would fail if Paint.NET had never been installed before, and was being installed to any non-default directory. This bug only affected version 3.22.

As usual, you can get this build from the built-in updater (Help -> Check for Updates), or by downloading it straight off the website: http://www.getpaint.net/

Changes since Beta 2:

• Fixed: Various UI issues with the Levels adjustment.
• Fixed: When pasting text into the Text tool with Ctrl+V, it would hide the nub for moving the text.
• Fixed: If the startup tool was set to the Zoom or Pan (Hand) tool, then the toolbar would render incorrectly.
• Changed: Enabled some compiler settings which improve security via support for DEP (/nxcompat), and Windows Vista’s Address Space Layout Randomization feature (ASLR) (/dynamicbase).

As an aside, on April 1st the GIMP website had an interesting version of the Wilber image, and I have adopted it for my forum avatar for the time being …

Essentially, a RESX is an XML files with a big list of name/value pairs. I will refer to these as string names, and string values. The XML looks like this:

<data name="GradientTool.HelpText">
  <value>Click and drag to start drawing. Holding shift constrains the angle. Right mouse button reverses colors.</value>
</data>
<data name="GradientTool.HelpText.WhileAdjusting.Format">
  <value>Offset: {0}{1} x {2}{3}, Length: {4} {5}, Angle: {6}°. Holding other mouse button will move both nubs.</value>
</data>

The RESX files for translations are in the same format and should have all the same string names. The <value> elements should have different text in them however (it should be translated!). At runtime, both the translated and original RESOURCES files are needed — the latter is used as a "fallback" in case a string is not defined in the translation. Whether this is an error is up to your translation process and resource loader code. Sometimes you want that behavior, such as if you have the base "EN" (English) translation and then some strings must vary for "EN-US" (U.S. English) or "EN-GB" (British English). You can store common string definitions in "EN", although usually it is better to completely duplicate the content, and use a tool to maintain the duplication.

Having worked with RESX files on Paint.NET and elsewhere, the following problems come up:

1. You could use the same string name twice. The RESX compiler will simply grab one of them, either the first or the last (I can’t remember). This is a problem if you go to update a string later and you change the wrong one. Then, your changes might not show up in the main program and you won’t know why. And you’ll have a heck of a time figure it out.
2. A translation could be missing some string names. If this happens, generally the fallback text (usually English) will show up. That is probably not the desired behavior, although in Paint.NET there are a few places where it’s okay. Translating a technical acronym for a pixel format, such as "A8R8B8G8", isn’t really necessary.
3. A translation could have extra string names defined. This is likely to happen if strings are removed from the original RESX, but the translation hasn’t been updated yet. This will not cause any errors, it is just extra cruft that can accumulate if you don’t pay attention (most professional translation teams have tools which handle this case automatically).
4. A string value could have "malformed" formatting tags. In the XML listed above, the second text has formatting tags such as {0} through {6}. These represent values which must be supplied at runtime by the application. There are two hazards here. One is that you could have formatting that String.Format(…) doesn’t like, such as having a { without a closing }, or vice versa. The other hazard is if a translation defines extra formatting tags, such as if a {7} was added above. Then your application will crash when it goes to apply formatting to that string. This is mostly a problem when strings have not yet been updated for a newer version. The translation may define fewer formatting tags, and this may or may not be an error. You may have a formatting tag that represents a piece of text that is not necessary to display in a particular translation.

Luckily, all of these can be checked for with some simple automation, which is what I have done with ResXCheck. I will be including its code in the next Paint.NET source code drop (for v3.30), and plan to tag it as "public domain" (just the utility, not Paint.NET itself). In the mean time, here’s a little utility function that can help you load a RESX and convert it to an IEnumerable of type KeyValuePair<string, string> (duplicate string names are not removed — this is important for being able to check #1 above).

using System;
using System.Collections.Generic;
using System.Linq;
using System.Xml.Linq;
using System.Xml.XPath;

// Given a file name for a RESX, returns a non-consolidated list of string name/value pairs.
IEnumerable<KeyValuePair<string, string>> FromResX(string resxFileName)
{
    XDocument xDoc = XDocument.Load(resxFileName);

    var query = from xe in xDoc.XPathSelectElements("/root/data")
                let attributes = xe.Attributes()
                let name = (from attribute in attributes
                            where attribute.Name.LocalName == "name"
                            select attribute.Value)
                let elements = xe.Elements()
                let value = (from element in elements
                             where element.Name.LocalName == "value"
                             select element.Value)
                select new KeyValuePair<string, string>(name.First(), value.First());

    return query;
}

To check for duplicates, a simple query such as the following is all that’s needed:

var resx = FromResX("strings.resx");

var dupeItems = resx.ToLookup(kv => kv.Key, kv => kv.Pair)      // 1
                    .Where(item => item.Take(2).Count() > 1)    // 2
                    .SelectMany(item => item.Select(val =>      // 3
                         new KeyValuePair<string, string>(item.Key, val.Value));

// 1 — converts from KeyValuePair<string, string>[] to IEnumerable<IGrouping<string, string>> — essentially a list of keys, each of which has a nested list of values
// 2 — finds any key which has 2 or more values in it. the "Take(2)" is an optimization
// 3 — convert back to a list of key,value pairs (probably not necessary if you use the "T-SQL" style syntax)

You can then do a foreach() over this virtual list and print out the key,value pairs. I could have written that query using the more succinct "T-SQL" style query syntax, but I hadn’t yet learned it when I wrote that part of the code. ResXCheck was a little project I took on to force myself to learn more about LINQ. Surprisingly, it only took about 2 minutes to learn the more compact query syntax.

I’m quite happy with LINQ. It’s letting me do some powerful data manipulation with very succinct, expressive code. And it’s very simple! I’ve already found a few mistakes in my RESX files, and they will be easy to fix. This tool will also help volunteer translators who publish their translations on the forum. I know it is hard to validate these things for correctness sometimes, especially for problem #4 list above.

Oh and for fun I made the utility parallelize the processing so you can validate "N" number of translations at the same time. Sadly, on my quad-core box it only dropped the validation time from 560 milliseconds down to 300. If I only have 50 more translations, then I could really stress it!

public static class Extensions
{
    public static IEnumerable<T> ToList<T>(this Func<T> sampleFn)
    {
        while (true)
        {
            T val = sampleFn();
            yield val;
        }
    }

    public static IEnumerable<T> While<T>(this IEnumerable<T> list, Func<T, bool> whileFn)
    {
        foreach (T item in list)
        {
            if (whileFn(item))
                yield return item;
            else
                yield break;
        }
    }

    public static void Execute<T>(this IEnumerable<T> list)
    {
        foreach (T item in list) { }
    }

    public static IEnumerable<T> Do<T>(this IEnumerable<T> list, Action<T> action)
    {
        foreach (T item in list)
        {
            action(item);
            yield item;
        }
    }
}

class Program
{
    public static void Main()
    {
        Func<string> inputSampleFn = Console.ReadLine;

        var input = inputSampleFn.ToList()
                                 .While(s => s != null);

        var query = input.Select(s => s.ToLower())
                         .Where(s => s.Contains(".dll"));

        query.Do(s => Console.WriteLine(s))
             .Execute();
    }
}

Now, compile this to something like "dllFilter.exe". Then run, at the command line, "dir c:\windows | filter.exe". Neat

(click for full size, 1600×1200)

I’m not surprised, but I felt the need to verify this anyway I’ll make sure the website lists Windows Server 2008 as a supported OS on the next update.

As an interesting side note, having access to systems with 4 and 8 cores has brought up an interesting performance problem in Paint.NET, and key insights for optimization and design going forward. In the past I have done a lot of work to ensure that certain key rendering code is multithreaded, and as such going from dual- to quad- to octa-core has yielded healthy performance gains. Even on these systems, quite often, I just can’t get CPU usage all the way up to 100%! Just look at the screenshot above: even on a very compute-intensive effect such as Julia Fractal, at highest quality, on a 16,000 x 9,000 pixel canvas (yes that’s 144 megapixels), the CPU usage is bouncing around and clearly not anywhere close to full performance. I guess the silver lining here is that power consumption is a little lower as a result, eh?

Even on my personal quad core desktop, I’m lucky if rendering a large gradient can hit 65% CPU usage. There’s a lot of wasted performance by having the rendering pipeline set up the way it us. Hopefully my talks with the .NET Parallels Extensions team will help me to improve this situation, while also putting some extra “real world” code in their laps to play with. With the current design, I wouldn’t be surprised if Paint.NET could barely keep a 64-core system more than 15% busy.

Also, I’d like to point out another exciting project related to things like concurrency and parallelism: Microsoft Live Labs Volta. I had a meeting with them last Tuesday and their approach to asynchronous, stream/event-based programming just blew my mind. Their project as a whole is actually targeted for some kind of simplified web cloud tier-distributed development*, but they have a concurrency runtime which could prove extremely valuable for the two rich client/desktop applications that I currently work on**. I’m very excited – anytime somebody sends me a meeting request titled, “Discuss monads and composition in the context of asynchronous computations,” I am reassured that there are still smart people out there working on cool things. I’m not sure how much I can discuss publicly about their stuff, but once I get any kind of green light I’m sure I’ll start gushing. I’ll leave you with one quote from the discussion that I actually made sure to write down, as it embodies something I’ve been struggling and searching for with respect to this type of coding:

“By construction, these things are correct.”

More on what that actually means later. I’ve got a lot of thoughts on parallel/asynchronous, concurrent, and functional programming and how it relates to multithreading, correctness, and performance. Hopefully I can put some of that into writing!

* This is not an exact definition
** That would be 1) Paint.NET, and 2) the other one that I work on at Microsoft (”my day job”).

Not only does Paint.NET need to be protected by crashing or "bad" plugins, but it needs to be protected from itself! Things like the Open/Save and Print dialogs are a good example, especially because they deal with external, "native" components. Some people have shell extensions installed that cause the Open/Save dialogs to fail, hang, or crash, and this breaks Paint.NET! This could be something as seemingly benign as a thumbnail provider for DivX videos. Yes, I get crash reports on the forum for that every so once in awhile. Why should Paint.NET have to crash if there’s a corrupted DivX video in a folder you’ve navigated to via File->Open? I’d rather crash just the Open dialog, detect the error without corruption in the main process, and then re-run the dialog in some kind of compatibility or reduced functionality mode. At least that way if it corrupts memory, then that corruption only affects the hosting process that it lives in.

So, there needs to be a really easy way for me to write a component in Paint.NET — whether it’s "built-in" or a "plug-in" — that can be isolated and not cause problems for the rest of the application. This means I want to host it in an external process and communicate with it, and then have a layer of abstraction in place for creating a "remote", isolated object.

The new System.AddIn namespace in .NET 3.5 provides a whole system for this, but honestly I find it to be way too complex, confusing, and involved. They have host views, add-in views, host-side adapter, add-in side adapters, etc. It’s a bunch of terminology that seems invented — why not just say client and server, proxy, tear-off, etc.? Every time you add a new interface or type you have to add code that spans at least 3 assemblies. Plus, they do not provide the ability for me to be running in a 64-bit process and have it communicate with an add-in that requires 32-bit hosting. This is important for certain plug-ins which are doing native interop to DLL’s that are only available in 32-bit (the VTF File Type Plugin comes to mind). They also do not provide the ability to activate an add-in that needs to run at a higher security level — for instance, if I want to require my Settings dialog to run with administrator privilege. I don’t want to have to deal with UAC at the code level, and would prefer it to be abstracted away. They also enforce a specific directory structure, and so on … anyway, it’s just too much and also too little.

.NET Remoting isn’t really an end-to-end solution for what I need, as it does not provide a hosting process. COM provides component hosting in an external process, but it seems like major overkill to register my .NET components as COM-proxied objects. Windows Communication Foundation is more for "enterprise" remoting and communication scenarios.

So it looks like I may have to roll my own solution, using System.IO.Pipes (actually I may prefer an HWND and WM_COPYDATA for marshaling) and borrowing heavily from the lessons put forth by System.AddIn (they have a very good story for versioning), and learned from my inbox full of crash logs. In any case it must be something that is easy to use by both the "host" and the "add-in" (or "built-in" :)). I’m thinking code generation will be very handy here in order to be able to declare an isolatable interface and then auto-generate the local tear-off/proxy, client stub, server stub, and registration glue.