Jump to content


Recommended Posts

The small increase in performance you get coding in C++ over C# is hardly enough to offset the headache of coding in the C++ language.

Just so you know, it would be possible to code a plugin in C++. But, with CodeLab available for free... why bother?

Link to comment
Share on other sites

The only plugin that I know of that was written in C++ is the JPEG 2000 plugin.

Although some plugins use PInvoke to call C / C++ code from C#, my WebP Filetype plugin does this for instance to run the WebP compression / decompression.


Plugin Pack | PSFilterPdn | Content Aware Fill | G'MICPaint Shop Pro Filetype | RAW Filetype | WebP Filetype

The small increase in performance you get coding in C++ over C# is hardly enough to offset the headache of coding in the C++ language. ~BoltBait


Link to comment
Share on other sites

It can be done, if you're using C++/CLI. You can actually create a "mixed-mode" assembly, where you would basically have a managed (C++/CLI) "front-end", but then your rendering kernel could be "pure native" on its own. It would about the same as splitting it up into 2 DLLs, one managed and one native, with the managed one P/Invoking to the native one.

Paint.NET does this itself. The SystemLayer.Native DLLs have both managed and native code. In 4.0 I've combined SystemLayer.Native and Native; even GPC and Squish are part of that DLL, and they are "pure native" code that the rest of Paint.NET uses P/Invoke to access. I have also added functions to implement fast-paths for things like filling memory, transforming points by matrices, layer blend modes, etc., with SSE2 optimizations.

C++/CLI is a bit of a bear though. It just depends on what you're willing to put up with I guess.

The biggest detail to remember is that C++/CLI cannot be compiled for "Any CPU". So you need 1 DLL for each CPU target. Currently that means x86 and x64, but will include ARM eventually. When you toss it into the Paint.NET Effects folder, Paint.NET will try to load all of them but only the one for the current CPU architecture will succeed. You'll end up with stray errors in "View Plugin Load Errors," but oh well.

I think some people have had luck using Visual Basic as well. However, I haven't gone to great lengths to ensure CLS compliance in the Paint.NET DLLs. (I wonder if this prevents F# from working? I haven't heard of anyone trying though.) C++/CLI should have no trouble though, it just requires you to know exactly what you're doing.

The Paint.NET Blog: https://blog.getpaint.net/

Donations are always appreciated! https://www.getpaint.net/donate.html


Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...