In the announcement post for 4.0.17, I mentioned that there was a new “portable mode” and to “see blog/forum post for details.”

What does it do

1) This will move Paint.NET’s internal AppSettings (not to be confused with .NET’s idea of “appSettings”) to be stored in a JSON file called PaintDotNet.AppSettings.json. Since it’s JSON you can use any JSON tools to read, write, or process it. The location of this file is not currently configurable; it will always be in the same directory as PaintDotNet.exe.

Paint.NET’s internal AppSettings covesr things like the window positions and sizes, and any changes you make in Settings (e.g. Tool defaults), as well as the settings you use for saving files (e.g. JPEG quality).

2) The updater will not be enabled in this mode, and the UI for it will not be available in the Settings dialog.

3) At startup, Paint.NET checks to see if there are any missing files from the installation. If anything’s missing, it offers to run a repair. Since repair is done by reinstalling the MSI, and this isn’t possible in portable mode, this behavior is also disabled.

4) Effect plugins can actually query the install type/state via the IAppInfoService and the InstallType property. Use the GetService() method to do this. I’m not sure if this will be useful Smile

How to enable it

You’ll have to modify the file PaintDotNet.exe.config. In general, I don’t recommend doing this, as there are some weird and scary settings in there which have been collected and fine-tuned over the years to craft just the right behavior for Paint.NET’s use of the .NET Runtime. But, this file is also capable of holding application-specific settings for some bizarre reason.

You’ll want to add a new setting called PaintDotNet.EnablePortableMode with a value of true in the <appSettings> section, toward the bottom of the file:

<?xml version="1.0"?>
<configuration>
  <runtime>
    <gcAllowVeryLargeObjects enabled="true"/>
    <generatePublisherEvidence enabled="false"/>
    <legacyCorruptedStateExceptionsPolicy enabled="true"/>
    <loadFromRemoteSources enabled="true"/>
  </runtime>
  <startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6"/>
  </startup>
  <appSettings>
    <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" />
    <add key="PaintDotNet.EnablePortableMode" value="true" />
  </appSettings>
</configuration>

How to get a “portable” copy of Paint.NET

With this addition, you should no longer need to go to a 3rd-party site to get a “portable” version of Paint.NET, although maybe they’ll still offer some added value that I’m not aware of, like also including a “portable” copy of the .NET Framework 4.6.

All you need to do is:

  1. Install Paint.NET on any system
  2. Copy the installation folder, which is usually C:\Program Files\paint.net, to a USB stick (or wherever)
  3. Enable “portable mode” as described above, by editing the .exe.config file
  4. Take the USB stick to any other PC that already has .NET Framework 4.6 installed, and then run PaintDotNet.exe
  5. Voilà! Now you have a portable copy of Paint.NET.

Conclusion

And there you go Smile Paint.NET has already been capable of running “portable” with respect to its installation dependencies, other than .NET itself, due to changes in the Visual C++ runtime and Universal C Runtime deployment peculiarities. The ability to route the app settings to a local file, however, is a new addition, and will ensure that Paint.NET doesn’t feel like it’s been “reset” every time you run it on a new computer.

This update improves performance and fixes a lot of small issues.

As usual, you can download the update directly from the website, or you can use the built-in updater via Settings –> Updates –> Check Now.

This is a minor update in the sense that it’s mostly a basket full of fixes and improvements. To me it feels like a larger release though Smile While it doesn’t have any new features, it’s fixing and cleaning out a whole bunch of longstanding things that I’ve wanted to tackle for awhile. I’ve been chipping away at things pretty steadily since the release of 4.0.16, so this really is about 3 full months worth of fixes and improvements! At Microsoft we would’ve called this an “MQ” (Milestone Quality) release.

For instance, the animation timer in version 4.0.16 runs at 120Hz. Always. The Win32 APIs for correctly detecting the monitor’s refresh rate are such a maze. They are archaic, bizarre, and the documentation is barely satisfactory. For this release I finally took the time to figure it all out and get the timer to run at the monitor’s actual refresh rate (it also works if you move the window across monitors with different refresh rates). I’m thinking of writing a blog post about it, in fact, because I don’t think anyone else should have to deal with that ever again. It sounds like it should be so simple, but there are always peculiarities and ambiguities that can trip things up. Not too surprisingly, this improves performance if you’re opening a lot of images: the image strip up at the top of the window uses several animations and it really gets bogged down, but now it’s actually much faster. This should also help battery life for laptop users (it won’t change things much for my new overclocked i9-7900X Winking smile).

Also, there are a handful of bugs in Windows and Direct2D that this release is working around. The “Creators Update” for Windows 10 includes the .NET Framework 4.7 and they totally broke the way mouse cursors work for WinForms in high-DPI situations. The result was that 4.0.16 has some really ugly mouse cursors if you’re running at anything other than 100% scaling (aka 96 DPI). So I spent a bunch of time to work around that and write completely custom cursor loading code, which also came with the bonus of providing me with new control over how this whole system works within Paint.NET. The Win32 cursor system is an old, archaic, weird system, one that’s made worse by the various wrappers which are built on top of it (e.g. WinForms or WPF). Now I’ve got the ability to provide high resolution and high color cursors. I can do pretty much anything with them now, and would like to upgrade the Win95-era cursors in a future release.

Also, I’ve implemented a “portable mode” that I’ll be describing in a follow-up post. It redirects the app’s settings into a local JSON file instead of having them in the registry. I know there are at least a handful of people who’ve been hoping for something like this for a long time – now your USB key can carry your personal settings with you from computer to computer.

Next up for Paint.NET: Windows Store! Once that’s done, I’m planning to upgrade the brushes system. It desperately needs more built-in brush shapes, as well as the ability to install custom ones.

Anyway, without further ado, here’s the change list!

  • Added: "Fluid mouse input" option in Settings -> UI -> Troubleshooting. If you see major glitches while drawing, try disabling this.
  • Improved: Default brush size, font size, and corner radius size now scales with major DPI scaling levels (brush size of 2 at 100% scaling, brush size of 4 at 200% scaling, etc.)
  • Improved: Default image size now scales with major DPI scaling levels (800×600 at 100%, 1600×1200 at 200%, etc.)
  • Improved performance and drawing latency by removing explicit calls to System.GC.Collect() except when low memory conditions are encountered
  • Improved performance by greatly reducing object allocation amplification by reducing the concurrency level when using ConcurrentDictionary, and by removing WeakReference allocations in favor of direct GCHandle usage
  • Improved: Performance and battery usage by ensuring animations always run at the monitor’s actual refresh rate
  • Improved (reduced) CPU usage when moving the mouse around the canvas
  • Removed: "Hold Ctrl to hide handle" from the Text tool because it was not useful and caused lots of confusion
  • Fixed: Various high-DPI fixes, including horrible looking mouse cursors caused by a bug in the latest .NET WinForms update
  • Fixed: Gradient tool no longer applies dithering "outside" of the gradient (in areas that should have a solid color)
  • Fixed: Very slow performance opening the Effects menu when lots of plugins are installed after installing the Windows 10 Creators Update
  • Fixed: When cropping and then performing an undo, the scroll position was totally wrong
  • Fixed a rendering glitch in the Save Configuration dialog (it would "wiggle")
  • Fixed: At certain brush sizes, the brush indicator on the canvas had a visual glitch in it due to a bug in Direct2D
  • Fixed: Text tool buttons for Bold, Italics, Underline were not localized for a few languages
  • Fixed a rare crash in the taskbar thumbnails
  • Fixed: Drawing with an aliased brush and opaque color (alpha=255) sometimes resulted in non-opaque pixels due to a bug in Direct2D’s ID2D1RenderTarget::FillOpacityMask
  • Fixed: "Olden" effect should no longer cause crashes (it still has some rendering artifacts due to its multithreading problems, however)
  • New: Portable mode can be enabled via a setting in the .exe.config, which will redirect app settings into a local JSON file (see blog/forum post for details)

Enjoy! Smile

Okay so the cat’s already out of the bag. A number of tech media outlets picked up on an innocent little comment of mine on the forum :

It’s at the top of my list. I’m going to release a 4.0.17 update and then focus just on pushing to Windows Store.

So there you have it Smile You can all stop e-mailing me asking about this all the time. I’m traveling for work right now but when I’m back, my plan is: 1) release 4.0.17 which has some important fixes for performance and  high-DPI, and then 2) focus exclusively on bringing 4.0.17 to the Windows Store. I’d love to give a date but I’ve always gotten them wrong. There may also be a 1.5) or a 3) in there because my code signing certificate is expiring soon and obviously I need to renew it. Hopefully that won’t be too onerous.

4.0.17 will also bring “native” portable-ness to the app, by way of a .exe.config setting to redirect the app’s settings into a local JSON file (instead of going to the registry). Should be a neat feature for some people.

Some people have asked, “but how will you make money with the Store version?” (I’m still planning on a price of “free”) Answer: not sure. But if I wait to figure out both of these things (money + Store logistics), I’ll procrastinate forever and neither will ever happen. It’s just something I’ve learned about my own psychology: don’t let X delay Y, just do Y and X will sort itself out later.

I was inspecting the latest build of Paint.NET with SciTech Memory Profiler  and noticed that there were a lot of System.Object allocations. Thousands of them … then, tens of thousands of them … and when I had opened 100 images, each of which were 3440×1440 pixels, I had over 800,000 System.Objects on the heap. That’s ridiculous! Not only do those use up a ton of memory, but they can really slow down the garbage collector. (Yes, they’ll survive to gen2 and live a nice quiet retired life, for the most part … but they also have to first survive a gen0 and then a gen1 collection.)

Obviously my question was, where are these coming from?! After poking around in the object graph for a bit, and then digging in with Reflector, it eventually became clear: every ConcurrentDictionary was allocating an Object[] array of size 128, and immediately populating it with brand new Object()s (it was not lazily populated). And Paint.NET uses a lot of ConcurrentDictionarys!

Each of these Objects serves as a locking object to help ensure correctness and good performance for when there are lots of writes to the dictionary. The reason it allocates 128 of these is based on its default policy for concurrencyLevel: 4 x ProcessorCount. My system is a 16-core Dual Xeon E5-2687W with HyperThreading, which means ProcessorCount = 32.

There’s no way this level of concurrency is needed, so I quickly refactored my code to use a utility method for creating ConcurrentDictionary instead of the constructor. Most places in the code only need a low concurrency level, like 2-4. Some places did warrant a higher concurrency level, but I still maxed it out at 1x ProcessorCount.

Once this was done, I recreated the slightly contrived experiment of loading up 100 x 3440×1440 images, and the System.Object count was down to about ~20,000. Not bad!

This may seem like a niche scenario. “Bah! Who buys a Dual Xeon? Most people just have a dual or quad core CPU!” That’s true today. But this will become more important as Intel’s Skylake-X and AMD’s Threadripper bring 16-core CPUs much closer to the mainstream. AMD is already doing a fantastic job with their mainstream 8-core Ryzen chips (which run Paint.NET really fantastically well, by the way!), and Intel has the 6-core Coffee Lake headed to mainstream systems later this year. Core counts are going up, which means ConcurrentDictionary’s memory usage is also going up.

So, if you’re writing a Windows app with the stock .NET Framework and you’re using ConcurrentDictionary a lot, I’d advise you to be careful with it. It’s not as lightweight as you think.

(The good news is that Stephen Toub updated this in the open source .NET Core 2.0 so that only 1x ProcessorCount is employed. Here’s the commit. This doesn’t seem to have made it into the latest .NET Framework 4.7, unfortunately.)

This is a hotfix for a crash that results from copying images from some web browsers. Unfortunately this seems to be the result of a bug in either the .NET Framework or Windows. I’ll try to follow up with folks at Microsoft when I have some time to do so.

As usual, you can download the update directly from the website, or you can use the built-in updater via Settings –> Updates –> Check Now.

Change log:

  • Fixed a crash or hang that sometimes happens when copying images from Internet Explorer, Edge, or Firefox, and then using File->New or Edit->Paste in paint.net.

    This is a hotfix that fixes a crash in the Magic Wand tool.

    As usual, you can download the update directly from the website, or you can use the built-in updater via Settings –> Updates –> Check Now.

    The only change since 4.0.14, which you can read about here, is this:

    • Fixed a crash in the Magic Wand tool if it was used twice in a row with a selection mode other than Replace.

    Technically, it’s not "twice in a row" that causes the crash. It’s actually just using the Magic Wand tool, with a selection mode other than Replace, on any selection that is "pixelated". There are two common sources of pixelated selections: the Magic Wand tool, and the Rectangle Select tool. "Pixelated" selections are comprised solely of straight horizontal or vertical segments whose endpoints are at integer coordinates. This distinction is important because there are some great optimizations you can take advantage of when the data fits into this limitation. Sadly, one of my optimizations fell over in 4.0.14.

    *phew*! Enjoy 🙂

    This is a minor update that slightly improves the brush tools, and fixes a few weird issues that some people were seeing.

    As usual, you can download the update directly from the website, or you can use the built-in updater via Settings –> Updates –> Check Now.

    Changes:

    • Improved the performance of the Brush tools when antialiasing is enabled
    • Improved the quality of the Brush tools when antialiasing is disabled
    • Fixed: Edit->Paste wasn’t working with some images that came from Firefox (as discussed at https://forums.getpaint.net/index.php?/topic/111012-not-enough-memory-to-paste-from-clipboard/ )
    • Fixed: Improved the reliability of Image->Crop to Selection on 32-bit systems. Instead of crashing when it runs out of memory, it will just show an error.
    • Fixed: Reduced crashes when loading UI images caused by an unreliable Windows component ("System.ArgumentException: Parameter is not valid")
    • Fixed: When manually checking for updates in the Settings dialog and the user didn’t actually have the necessary security privileges, a crash might result instead of an error dialog.

    Enjoy! Smile

    This is a minor update that fixes a few high priority problems that many people were bumping into.

    As usual, you can download the update directly from the website, or you can use the built-in updater via Settings –> Updates –> Check Now.

    Changes:

    • Fixed "Missing api-ms-win-core-timezone-l1-1-0.dll" error that was being seen on some Windows 7 systems due to partial install or uninstall of Microsoft’s Universal C Runtime
    • Fixed the layout for the File->New, Image->Resize, and Image->Canvas Size dialogs in all known situations (various languages, DPI sizes, font configurations)
    • Fixed: Old versions of PSD plugin couldn’t load due to removal of PrivateThreadPool
    • Fixed a crash when typing a negative number for a zoom level

    Enjoy!

    This is a hotfix for some crashing on single CPU systems, and a rendering bug in the Rounded Rectangle shape.

    As usual, you can download the update directly from the website, or you can use the built-in updater via Settings –> Updates –> Check Now.

    Change log:

    • Fixed: Rounded Rectangle rendering was incorrect for some values of "Corner size"
    • Fixed: Effects and Adjustments were crashing the app on systems with only 1 CPU core, or virtual machines configured for only 1 CPU

    And, for convenience, here is the change log for 4.0.11:

    Enjoy!

    This update adds the ability to configure the Rounded Rectangle shape’s corner size. It also fixes issues with scrolling and panning, effect rendering performance, high DPI, and a rare system hang caused by WPF.

    As usual, you can download the update directly from the website, or you can use the built-in updater via Settings –> Updates –> Check Now.

    Change log:

    Enjoy!