Claude Code just helped make a very important scenario in Paint​.NET about 95% faster: Copy. To. Clipboard.

Why's it slow? Mostly it involves encoding a PNG, which is slow because it's single-threaded and involves a lot of computation and compression. It's also slow because WIC (Windows Imaging Component) is slow. It's not built for speed in this area, and even if it was it certainly hasn't been further updated/optimized in 10 or 15 years.

Every software developer makes mistakes, no developer can write 100% bug-free code.

I'm going to share potentially the most embarrassing bug I've ever caused, which I just discovered in Paint​.NET yesterday. I find it worthwhile to be transparent about bugs and not hide them or be ashamed of them. Personal humility about these things is a helpful thing for me, and also lets more junior developers see that even very experienced developers sometimes make BIG mistakes. I'm human too!

@migueldeicaza It’s not worth it for any amount. The physical and mental health tolls of working there are sky high. I was completely fried by the time I left after only 3.3 years. @migueldeicaza The internal propaganda is poisonous as well. “Voted Best Place to Work, N years in a row! We’re helping to connect the world! What you do has impact!”

If you drop the Count property from .NET's ICollection, ISet, IDictionary, then you can build up a really interesting LINQ-style query system. Where(), Intersect(), Except(), Union(), etc. ... all without any copying. Select() isn't really doable though, since you'd need a mapping function in both directions, T -> TResult and TResult ->T, so that the outer query can ask the inner query if it has the T that maps to the TResult (and you only know which T to ask for if you have Func<TResult, T>)

I just upgraded to an AMD Ryzen 9 3950X. It's faaaast.

The funny thing about perf in Paint​.NET is that a faster CPU can actually result in a lower framerate.

Hear me out ... A faster CPU can render more 128x128 px tiles per frame (~16ms usually).

More tiles per frame means more CPU time spent on Direct2D, copying bitmaps to the GPU, etc.

1/ So about 5 years ago I came up with something called the SingleUseCriticalSection. It's been happily guarding access to lazily initialized data (basically Lazy<T>) in Paint​.NET for about 5 years now, so I thought I'd share it: pastebin.com/1kx47Yw7 2/ Using Monitor (aka lock(object)) in .NET is pretty bad when there's lots of contention because you burn A LOT of CPU time on spin locks.

It's just terrible. A kernel-space sync primitive that actually sleeps the threads during contention is necessary

Here's the story of a game I made in 1994, when I was 12, that somehow -- like some kind of lost, drunken cat -- finally found its way home on Christmas Eve after 25 years.

THE GOLDEN FLUTE IV: THE FLUTE OF IMMORTALITY

cc @Macaw45 and @textfiles Here's a link into @macaw45's Twitch stream where he played the game two days ago: twitch.tv/videos/5255543…

And here's a link to an HTML hosted DOSBox where you can play it yourself: archive.org/details/msdos_…

(warning: it's not very good 😂)