I don’t often make “publicity posts” but I know a lot of people have been waiting for this. Microsoft just released the official Ribbon control for WPF (download link). It’s 100% WPF – it isn’t sitting on top of the Windows 7 or MFC Ribbon control, in other words.

This is not the same as what was released about 2 years ago in CTP form. This is brand new, released today. Samples and source code are included!

Office Word style UI using Microsoft Ribbon for WPF

Question I know people will ask: “Will you be using this in Paint.NET!?!?!?!”

Pre-emptive answer: Probably not. Paint.NET is based on WinForms, not WPF, and will likely remain that way. Plus, I have other ideas for what to do with the UI in v4. I’m not convinced the Ribbon is what I want to use. If I did use the Microsoft WPF Ribbon (and I’m not saying that I will, remember), I’d have to be very careful since correctly mixing WinForms and WPF can be a bit delicate. Stay tuned of course.

Bruce Bowyer-Smith has gone to the extraordinary effort to write a pack of GPU-accelerated effects for Paint.NET. It started out with a preview discussion in Plugin Developer’s Central that eventually led to a recent “public” release over in the normal Plugin publishing section.

The pack contains GPU accelerated versions of Gaussian Blur, Motion Blur, Radial Blur, Zoom Blur, as well as a new Channel Blur.

A GPU that supports DirectCompute is required along with Windows 7, or Windows Vista SP2 with the Platform Update (it needs DirectX 11, in other words). Most recent NVIDIA and ATI/AMD cards support this, although Intel’s do not. The latter is a big reason why I have not properly pursued this for Paint.NET yet – there is no high-performance software fallback for DirectCompute. (The “reference driver” does work, but is very slow because it’s intended to render “perfectly” without any regard to performance, and is mostly useful for GPU and driver engineers to make sure they are on the right track.)

It’s interesting to watch these effects execute, because they aren’t any faster on smaller images (and often slower). However, as the size of the image increases, the performance delta becomes very dramatic. The GPU versions just don’t seem to run any slower, while the CPU-based effects quickly lag far behind. These effects are probably hindered by Paint.NETs CPU-centric rendering model, so I wouldn’t be surprised if further performance jumps are possible.

The only downside I’m seeing is that, so far, it is limited to handling images that fit within the maximum texture size that your GPU supports. On a high end video card, that means 8,192 x 8,192 pixels (IIRC).

I’ve said for a long time that I didn’t want a “Settings” dialog in Paint.NET. I honestly felt that providing as few settings as possible, as well as reasonable defaults for the ones that did exist, was the best way to go.

However, it’s finally to the point where it actually makes sense to consolidate the few settings that Paint.NET has into a proper Settings dialog. This also opens up the ability to easily add new settings where it makes sense.

Here’s a preview:

The “Choose Tool Defaults” dialog will also be folded into this.

I’m using IndirectUI to auto-generate and auto-databind most of this. This is the same system that is used for most of the effect and file type configuration UI as well. It’s a versatile system and is saving me a lot of time. Getting the new application settings system (the data and storage model) up and running has taken a bit of time, but adding any new setting or settings section only takes a few minutes. The dialog here didn’t take much time at all, either.

Effect plugins will be able to query the “Default Quality Level” setting and apply it as they see fit, along with any other settings that end up being pertinent.

Oh, and I’m using DirectWrite to render all of the text now. It works really well, looks great, and is configurable (if you prefer the “GDI Classic” mode, well then just change the setting). Even the buttons are no longer using GDI+, and also have the animations that “real” buttons in the rest of Windows have (this is a change throughout Paint.NET, not just in the Settings dialog).

As usual, the icons are from the excellent Fugue Icon set.

In my last post I briefly mentioned that Rotate/Zoom had been converted to use IndirectUI. In the current release (v3.5.5) it is implemented with a custom WinForms dialog along with manual data binding, etc. It works fine and simply wasn’t a priority to convert in the v3.5 timeframe.

Well, here’s how it looks now:

It certainly fits in better with the rest of the UI now. The “roll ball 3D” control will also be available for plugins to use. In addition, thanks to some polite prodding by a prominent plugin author (pyrochild), I’ve added the ability to use the regular angle chooser control with a constrained range. Currently, only angle ranges of [-180, +180] and [0, +360] are permitted.

The greyed area shows the angle range that is not permitted.

I’m also planning to add the ability for IndirectUI-based effects and file type UI to use tab pages. This will be useful for having Basic/Advanced pages for file types, and to have more configurable effect properties without resorting to a “tall” UI dialog.

Anyway, that’s all for now!

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.