I sat down to write some notes before starting this blog entry, and I wound up with two full pages in OneNote on the 1920×1200 monitor it was sitting in. The more I’ve been working on it the more I’m excited about the Paint.NET v3.5 release. It isn’t one that introduces a lot of really cool or big-ticket features, but the list of small improvements is really adding up. I’ve been able to do a lot of research and prototyping in esoteric areas of multithreading and concurrency, and have gained both more mastery and more fear for these topics.
Performance work in Paint.NET v3.5 has wound up focusing on 3 areas:
- Scaling up. As everyone’s been saying for years, the future is increasingly multithreaded. My newest CPU upgrade leaves me with 8 threads in Task Manager (Intel Core i7 overclocked to 3.8GHz). A lot of research and work has gone into making sure that Paint.NET continues to scale with more threads, and that I have better tools for safely and correctly implementing this across more of the application.
”A high-end 64-bit Intel Core i7 desktop should run Paint.NET very fast.”
- Scaling down. Those $300 netbooks that are taking everyone by storm only run about as fast as what I was using 7 years ago (Pentium 4 at 2.0 – 2.5ghz). Clearly, classic optimization strategies are important as well: trimming cycles, removing or deferring code execution, and optimizing repainting.
“A brand-new netbook with an Atom processor should run Paint.NET comfortably.”
- Reducing memory usage. I guess this goes with scaling down. I made a bet a long time ago that 64-bit would slowly take care of the way I was allocating memory, which simplified development work but has had the consequence of consuming vast amounts of virtual address space . I was wrong: 32-bit will be here for a long time, especially since most of those hot-like-pancakes $300 netbooks are not 64-bit capable. This is currently my top reliability issue, as running out of memory causes Paint.NET to crash.
”It’s not all yours.”
I’ve had to split this discussion over several blog entries because otherwise it was too long and even I would have fallen asleep reading it. I’ll summarize the results here though:
- Images open much faster, especially on single-core/single-thread systems. Actually, I already wrote about this, so go read that first 🙂
- I ordered and assembled my own Atom-based mini-desktop (“nettop”), in order to keep myself honest as I was working on my Core 2 Quad QX6700 2.67 GHz monster and subsequently as I upgraded to a Core i7 920 2.66GHz overclocked to 3.8 GHz.
- The selection renderer has been completely rewritten. No more dancing ants and no more GDI+ means much lower CPU usage and better performance with multiple CPU cores.
- Much better CPU scaling for the image composition rendering pipeline using LINQ-esque functional programming and deferred execution techniques.
- A rewritten “render cache” has resulted in an average of 30-50% less memory usage when opening multiple images, especially those with just a single layer (PNG, JPEG). This means fewer out of memory crashes, and the ability to open more images without out-of-memory errors.
Paint.NET v3.5 is a stepping stone towards a hopefully epic v4.0. I’m slowly rebuilding the application from the inside out, and it takes a lot of time to do the necessary research and development. About 2 years ago, right around the time I was preparing to release Paint.NET v3.0, I had this nagging feeling in the back of my head that said basically “ur doin’ it wrong”. My document model was wrong, my application model was brittle, and I just couldn’t implement really cool features without using up a ton of memory. I also couldn’t provide features like scripting or a better extensibility model (plugins) in a manner that was both safe and powerful.
However, I didn’t really know how to solve all of this at a scale lower than the 50,000-foot view. Since then I’ve been slowly piecing together the tools and knowledge that I’ll need to create the best version of Paint.NET ever – one that’s great both outside (for users) and inside (for developers).
Now, if you’ll excuse me, I’ve got to stop breaking things and start fixing them so that I can push out an alpha release.
paint.net blog 
I am very curious about this – answer if you are comfortable if that: is the Paint.NET your prime business? From what I am reading on the blog you belong to 2% high-arcane-skilled programmers, and I would be very surprised if e.g. Microsoft didn’t put their hand on you.
Wow, your dedication is impressive! Easy to see why 4.0 is looking to be a blockbuster release.
One thing I recently came across is 16 bit image editing. I found a free program that can do that and I must say that the results are impressive! A huge improvement over 8 image processing.
So now I have to use 2 programs instead of only Paint.net!
Any plans to add this feature in the future (also waiting for layer masks in v4.0…)?
Anyway great work! Keep going!
Lorenzo
Looking forward to it. Keep up the good work! At this pace, 4.0 will definitely be “epic.” 😉
Although I don’t know that much programming I enjoy reading you blog. You have a enthusiasm for what you are doing that comes across in your writing. I don’t always understand but it makes me want to.
Keep up the great work.
Sounds really good.
I can´t wait testing it on this Windows 7, since it opens the old PDN faster and seems faster in nearly every CPU intensive application.
janislaw — I’ve been working at Microsoft for the last 4 1/2 years, although I took last summer off.
Lorenzo — I’ve had my eye on that as well. Like I said above, the document model is all wrong. The changes in v3.5 are preparatory to fixing it, which will also enable adding a feature such as diverse pixel formats.
3.5 DO WANT. And lolbird ftw.
I’m really glad that you managed to scale down the CPU and RAM requirements. For about three (four?) years now I’ve been running a single-core 1.8 Ghz (or 2.3, it can’t make up it’s damned mind) with about a gig of RAM and Paint.NET runs pretty reliably, but you getting it to work on a netbook means I shall have all the candiez… err, CPU for other stuff.
Any chance you’ll add support for OTF fonts any time soon?
If I may make a small suggestion: the plugin system wouldn’t necessarily have to be safe (not in an expensive way anyway) – plugins that don’t stick to The Rules will be killed anyway, so stating in The Rules that a plugin has to be safe under any condition would enforce safety without any code at all (and the fastest code is no code)
Also, how about a little bit of involving the GPU in effects? It’s kinda hard to do in the current effect model (well not hard as such, but it requires so much code just to get it going that it isn’t fast anymore – things like having to copy the image twice)
Any chance of multi-layer effect plugin support in v3.5 or this is 4.0-feature?
Why no more dancing ants, Rick? I’m so used to seeing those that it would trick me into thinking, “Uh-oh, bug!”
@Scotty
Because dancing ants take up heaps of CPU*
*Assumption
“•The selection renderer has been completely rewritten. No more dancing ants and no more GDI+ means much lower CPU usage and better performance with multiple CPU cores.”
Music to my ears Rick. That alone makes this release worth it in my eyes. 😉
I can’t wait for 3.5, this should be a really great update.
I’m a professional programmer and I’m still amazed from time to time how decent this program is made, and the extraordinary techniques you use to make this possible. Keep up the good work!
*also wants a tool with which you can blur 2 layers together along the edges, but without it I’ll still be very happy with Paint.NET 4.0 😀
Cristan Meijer: That should be possible with Paint.Net’s current technology. Just use the Alpha Gradient. :AlphaChannel:
Sorry to get off topic. Rick, at the risk of beating an old horse, is there any ETA on 3.5? Mind you, I’m excited, not impatient. 🙂
Me too. 😀
Hello, Rick Brewster!
Paint .NET is not very useful tool, it’s a very good example of programming using C# and .NET technologies.
But I have possibly one very big problem using Paint .NET – compatibility. I can even understand why Your application doesn’t support Windows 9x/ME – they are very old of course. But when I try to install Paint .NET 3.x in Windows 2000, I can’t believe, it doesn’t even install. It’s a paint! It must work everywhere. Windows XP and Windows 2000 are very similar. At least add checks for OS version in Your OS-dependent source code. You must not to test it thoroughly under Windows 2000, we (users) will do it for You. We don’t need source code, we need working application. I got 3.01 sources from some site and commented about 10 lines in source code. After that it worked under Windows 2000 without any problem. I expect at least unofficial support for Windows 2000 in Paint 3.x.
About SSE:
Again it’s a paint, so no need SSE. SSE are for video codecs. There speed may have a value. I don’t know why I need SSE CPU for drawing lines? Please just try simple C coding without SSE. I’m sure, native code speed will be good enough for many of us.
And x-core support is the same. You’ll get many many bugs, if compare with single-threaded application. You said, there are only four developers, but aim is wrong. Optimize Paint? What’s an aim? It was open-source, so it was good example of coding, but now, You’re doing it just for Yourself? or for Microsoft? or for money? or for experience?
But of course not for users. Please don’t forget word – compatibility.
Good luck in successful development!
Best regards,
Dmitry Stepanushkin
Dmitry, I have no idea where you’re getting your information and opinions from. You’re WAY off track though, and out of line.
Dmitry, WTF are you on about, and why are you still using Windows 2000 or earlier. Microsoft doesnt even support 98, and 2000 by next year why should other software. Please dont forget the word – Upgrade.
Please Keep up the great work Rick 🙂
For goodness-sake it has been clearly stated and announced that Paint.NET 3.x does not support Windows 2000 i believe???
One the key things I like about Paint .NET is it’s interface. It seems like a step forward from even Photoshop and keeping it native makes it feel much less botched than CS4.
I realise Photoshop CS4 and Paint .NET are different ends of the spectrum, but I am heartily impressed by PDN.
I think you are headed in the right direction with 3.5. 3.4 runs super fast under Win7.
Do you plan on using WPF for version 4? If so please use a standard metaphor for PDN as my major bugbear with CS4 is it totally (ugly) non standard interface.
Chris — Not sure about WPF. I’d love to use it; I’ve been learning up on it a lot recently. But Paint.NET would have to be turned inside out to do it. Not sure if that’s feasible.
I might take an inside-out approach and tackle it over multiple releases. Start with the canvas and work outward 🙂
I don’t know if supporting WPF would provide some 3d acceleration to PDN?
It was just a thought, but hell its not like PDN looks like the GIMP at the moment is it 😉
You managed to implement a far better version of image tabs than Adobe did in CS4, though Elements 3 had a better system than CS4 as well.
I’m just wondering if PDN will ever support Drawing Tablets on Windows XP Home SP2. But anyhow…
I think Paint.NET is certainly great, especially the interface, which I think is rather clean. Photoshop is something I simply can’t use; I’m too used to PDN! 😀 Good job, Rick! Can’t wait till v4.x comes out! PDN is certainly powerful, and I’m sure one day, it’ll be one of the well-known names in graphics software.
I cannot believe how amazingly this program has progressed. I have only been using Paint.NET for less than half of a year, and yet it has inspired me to find my true passion for graphic design. This program has helped me out in so many ways, and I would really like to thank everyone who has put forth an effort into making Paint.NET and even the forums a better place to be. Thanks Rick for all your hard work, and I cannot wait till v. 3.5 and 4.0 are released!
Hi,
You should have a look at what .NET framework 4.0 is bringing to the party in terms of parallel computing and especially the Task concept (http://www.danielmoth.com/Blog/2008/12/introducing-new-task-type.html).
I do not think it is worse doing big optimizations for // execution on multi core machines using good old threads when that kind of stuff is around the corner 😉
If you plan your work around tools that haven’t even been released, you’ll never actually get the work done. You can’t target a nonexistant platform. So we’d probably be waiting 18-36 months past the release date of .net 4.0 if he decided to wait for that, plus he’d have to have time to learn the new environment aside.
While it’d certainly make me happy to have a .net 4 ver of paint.net sooner rather than later, it certainly isn’t something we should even bother asking about until after 4 is released…and even then, you won’t get much of a response.
SilverDK — I know some of the people on that team, we have a good relationship 🙂 I’m interested in their stuff, and they like my stuff.
Craig B — True. I’m keeping an eye on .NET 4 stuff, but I’m proceeding with Paint.NET v3.5 using .NET 3.5 SP1.
Great to hear.
We all think you’re on the right direction :-).
Thanks for all the great work, and it’s awesome that you tell people your design philosophies and reasons. Rather than moving everything into WPF, which PDN wouldn’t benefit from a whole lot, I would rather see effort made toward targeting Mono and non-Windows platforms. I know there’s probably some tricky platform dependent code in PDN, but this would strengthen your user base and increase support both in extensions and general knowledge. I would also be really interested in seeing work on making many of the core features and manipulations available in library form so people can use “Powered By Paint.NET” image manipulation in their own applications, though I’m not sure how feasible this is. It’s been a while since I looked at the object model, but last time I was playing with it I also wished there was a way to create custom tools.
v4 of the BCL has some interesting enhancements that PDN can benefit from, but I don’t think there’s any reason to completely discard the parallelism systems you’ve already put in place, especially since you would lose your extensions, but I’m sure there will be a way either to migrate existing code or at least leverage it for an “enhanced” extensibility model in the future.
-TheXenocide
P.S. Any chance of a skew feature, selection manipulation (free rotate, etc.) or select alpha? I know the select alpha can be done with some extra clicks but it’s a common and, in this case, easy feature to implement while the other features are on the ground floor of the competition.
Hehehe, silly me putting my foot in my mouth, feel free to ignore feature requests for those already implemented. *whistles innocently*
TheXenocide — Paint.NET would greatly benefit from WPF. I don’t see enough benefit vs. cost for doing any portability work, Mono or Mac OS or Linux or otherwise. It’ll never ever happen. Paint.NET is not going to be available in library form.
I am really forward to see it in action. Especially the selection as it used to be one of the “caveats” if we can call it like this for such a great software 😉
I really look forward to the multithreading optimizations. I run a Phenom II X4 810 and would love to see this thing RAWR! Not purr, but a full out RAWR!!
I run 64-bit and Paint.NET is one of the few programs that takes advantage of this. This and my VirtualBox…
Looking forward to a 3.5 release.
deltatux
Hey,
You’ve got a great app here.
The exciting thing about the 4.0 release could be super multhithreading with the TPL library that’s coming out in the framework 4.0!
Have you thought about using the Microsoft CCR for your threading needs? Watch the case study videos here: http://www.microsoft.com/ccrdss.
I’ve been using it a lot lately. It’s a work of art!
Stacy
` Another Person hoping for platform agnostic paint made in C# | GTK#.
Zachariah — Sorry, it’s not going to happen. (not Paint.NET anyway)