Rick Brewster

@null54 you can do some additional debugging by making your own implementation of IBitmap[Source]. Derive from BitmapSourceBase<TPixel> and then also implement IBitmap<TPixel>. In your implementation you can use whatever allocator you want, e.g. NativeMemory, so you can employ whatever stride you need to help you narrow down where the problem is.

@BDP, probably won't help -- they already did a clean install of the entire OS. And if you need the latest drivers for a GeForce (930A in this case) just go to nvidia.com, no need for some random utility program. It really does look like a failing/failed GPU. The vertices for the selection data are obviously mangled, and nothing short of blatant memory corruption somewhere along the way could cause that.

I can't seem to figure it out from looking at the code 🤔 But from looking at the screenshots, my guess is there's (at least) a bug with how the per-row output pointer is being calculated. Notice how it has a transparent chunk at the bottom. This could happen if the destination stride was not taken into account, and if that stride was a bit larger than the width*bytesPerPixel. It looks like maybe about 10% wasn't filled in? So maybe the output is ~900px wide, but the buffer is ~1024px wide (with 3600 byte stride). I can't really discern a specific pattern in the output pixels -- it's obviously not just the left portion of the image, which sometimes happens if bytesPerPixel is incorrectly applied (e.g. only filling or utilizing the left 25%, or something like that)

Hmm. If you've got a link to the code in question, I can take a look and see if I can figure something out

padding.left is not being multiplied by the bytes-per-pixel? Also there are methods in PaintDotNet.Imaging.BitmapUtil that will make your life much easier for calculations like these, like GetRowPointer and GetPointPointer

Then that's probably just a bug in the plugin, or you're using it outside of what it's capable of doing. This is a very old plugin, I'm not sure what can be done.

It depends on circumstances. Bitmap allocations are pooled/recycled, and I also try to pool/recycle Direct2D device contexts along with the bitmaps they were wrapped around (via IDirect2DFactory.CreateBitmapRenderTarget(), which has special/private performance advantages vs. other paths). In order to reuse these bitmaps and their DCs better, I do some trickery with the strides to reduce the need to recreate device contexts (which aren't cheap, so this improves perf by quite a good amount). See BitmapUtil.GetOptimalStrideChecked() for more. Is the "corrupt" bitmap being drawn by the 8BF plugin? It may not be doing the right thing when it comes to stride -- a lot of code out there incorrectly assumes that stride==width*sizeof(pixel), which almost always works ...

Then it’s a bad GPU. Replace it — could use a friend’s temporarily to see if that helps

I'm curious about this too -- this type of information is very useful for me!

I've updated the instructions in the first post so that they no longer instruct you to put files in the root Paint.NET folder. I was hoping @midora would update the instructions for their plugins since the release of v4.3, but this has not happened.

It sounds like you're aware of the limitations of each app you're using. You'll just have to keep these limitations in mind as you go about your business.

That might be something that folks on the C# Discord Server can help figure out.

That appears to be the same crash reported in the post above yours by @user.by

That should only happen if you're using the portable version of Paint.NET (which can't use the protocol method). Or, of course, if you're using an extremely old version of Paint.NET that's not even compatible with the plugin. Or, you're conflating the two instructions. paintdotnet: (protocol) is generally used via "Run", whereas the other command is run from the command prompt (as null54 stated).

A bug in Firefox and/or Confluence

It's not really a bug, and it's not difficult to reproduce. @toe_head2001 just told you exactly what leads to it.

And/or adjust the Resolution (aka DPI) in Image->Resize.

Reinstalling to paint-net is also not going to be an issue, as long as PsFilterPdn was reconfigured to the appropriate path (which it sounds like it was). So at this point there's no need to reinstall again to paint.net

To elaborate on this, you should be able to press Ctrl+S and then immediately press Enter without even having to wait for the Save Configuration dialog to pop up.

A plugin cannot do this, and I won't be changing this behavior. There's no need to move the mouse all the way over to the OK button -- just press Enter.

Which would gobble up more memory than exists Sorry, but this just isn't how things work, and it won't be changing

Nothing has changed here, so I'm not sure what was happening before. PDN has never copied the line/shape as an object, it can only copy the pixels themselves.

The ICO is already available -- just download the portable version, it's right there as paintdotnet.ico You should be able to choose which file types are associated with Paint.NET by using the "Default apps" settings page (just search for "Default apps"). Unfortunately that's just what Windows does for Store apps. I think it's an ugly leftover from Windows 8/8.1. If anyone knows how to fix this, assuming it's even possible, I'm all ears for it. There might be some new thing that can be done in the Appx manifest. I think the standard solution here is to create a batch file that uses the paintdotnet: protocol. Sometimes programs don't work very well when directly given the protocol, etc. "paintdotnet:%1", but they often easily handle batch files.

No but you can use something like Stable Diffusion for that

You're talking about the files that store the history entries. You can always save your image, close it, and then re-open it (File -> Open Recent -> first item, which you can do quickly by typing Alt+F, R, 1) Obviously this clears your undo history, but it's how you do it.