Is GDI+ in WPF backward?

[sowen]

At my first glance at WPF, I felt pretty exciting about those
BitmapEffect controls, it seems I can apply the graphical filters to
any control.

Yesterday I spent couple hours to study how to write my own
BitmapEffect, I didn't succeed. First, there are not too many
information online. There is a sample RGBFilterEffect though, however,
it doesn't work in my local machine, it hits the cmd.exe error. and I
couldn't find any solution, so I gave up; the downloaded compiled exe
can't run either (my machine has VS.NET 2005, VS2008 installed); and
this page (http://msdn2.microsoft.com/en-us/library/
system.windows.media.effects.bitmapeffect.initializebitmapeffect.aspx)
doesn't explain why I need to do those codes.

Anyway, my understanding is, in order to write a customized
BitmapEffect, I need to write the class in C#, and write a COM in C++,
then use them together. The process is confusing and complicated.

There is no way I can use c# to do lock the region, manipulate pixels,
then render the output. I disassemble the BitmapEffect, all I can see
it's COM calling. In .NET 2.0, GDI+ was encapsulated in some classes,
such as Bitmap and BitmapData. It was easy to write something
different. But in WPF, it's quite hard. I am sure there are some
reasons, but I can't help asking, is it a backward?

 

[Nicholas Paldino [.NET/C# MVP]]

sowen,

This post on MSDN forums might be of use, as it explains why you need to
use unmanaged code for a BitmapEffect, as well as some possibile managed
solutions in certain situations:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=927927&SiteID=1

Basically, the unmanaged code is used for pixel manipulation for
performance reasons. That doesn't mean you ^have^ to use unmanaged code
(since the entry point is through the managed code already), but depending
on the responsiveness of the app, it might not meet your needs.