Keith Cancel Posted September 3, 2011 Share Posted September 3, 2011 I was curious if there has been any attempts to write a plugin in C++? It appears the C# is used for plugin development primarily. Quote Link to comment Share on other sites More sharing options...
BoltBait Posted September 3, 2011 Share Posted September 3, 2011 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? Quote Download: BoltBait's Plugin Pack | CodeLab | and a Free Computer Dominos Game Link to comment Share on other sites More sharing options...
null54 Posted September 3, 2011 Share Posted September 3, 2011 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. Quote Plugin Pack | PSFilterPdn | Content Aware Fill | G'MIC | Paint 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 More sharing options...
Rick Brewster Posted September 3, 2011 Share Posted September 3, 2011 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. Quote 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 More sharing options...
Keith Cancel Posted September 4, 2011 Author Share Posted September 4, 2011 (edited) Hmm, okay I will look into this. I just was kinda curious. Edited September 5, 2011 by Keith Cancel Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.