Adobe introduces GPU based filter technology, will the WPF team respond?

MacOSX has had their Core Image API for a long time which abstracts you from the GPU. Now Adobe has stepped up to the plate by introducing a preview of a new toolkit who’s main technology is a new programming language, codenamed “Hydra”, that enables the creation of filters and effects that can be compiled down to run on the GPU (if GPU is not available, it falls back to CPU). Here’s their tutorial that gives an example of how to write a filter with Hydra. There’s also a gallery of sample filters available here. Kudos to Adobe for attempting to bring this technology to the mainstream.

So, the next question is, when are we going to see something similar for WPF and Silverlight? Sure WPF has BitmapEffects, but as anybody who is familiar with the BitmapEffects API knows, they are themselves completely CPU based and, in turn, also force whatever visuals they’re applied to be rendered on the CPU. This pretty much renders them a no-no if you’re trying to create a really fluid, animated UI… that is as long as you expect to have high frame rates.

People have been asking for this capability since WPF was announced.  Where you at Microsoft? 🙂 If only they documented MILCORE, maybe someone could tack it on for them…

6 thoughts on “Adobe introduces GPU based filter technology, will the WPF team respond?

  1. I really don’t get it. I am just amazed how advanced the technology Microsoft gives us, but they neuter the API.Take the Vista DWM. We see blured glass, Flip3D, etc. Can we leverage this power? No. We get 2D live thumbnails you can feed an hWnd to paint on.If we had real Direct3D integration with WPF, we’d be able to at least write pixel shaders to do GPU based bitmap effects. But I have a feeling that means giving us milcore.Why not give us that sort of API access? Maybe Balmer forgot his mission statement (http://youtube.com/watch?v=KMU0tzLwhbE). Maybe instead of spending so much time getting us the source of the .NET libraries, they can spend that time getting us milcore.What brings me down even more is Microsoft employees seem to elude that decent DWM and milcore access won’t be available in the “Vista time frame”. So do we have to wait another 5 years and buy another OS just to get what other OS’s/platforms have had for a decade?In the context of UI development, they had every opportunity to leap-frog the competition with WPF & Vista…but for some reason, Microsoft would rather break our hearts.-Jer

  2. Jeremiah,Couldn’t agree more. Unlike a lot of people I’ll never blame Microsoft for not adding every last possible feature everyone wants to their software, but when they spend the time creating something as powerful as MILCORE and then they don’t expose it to developers, it’s just dumb.I’m hoping that when the WPF source code becomes availalbe we’ll be able to gleam a little bit about MILCORE from it.Cheers,Drew

  3. I was thinking the same thing about the WPF source and milcore. Looking at the dlls in Reflector don’t do much more than confuse a brotha, so maybe the source-code comments will clue us in a little (if they don’t remove the milcore comments =) ).But even then, comparing the Reflector code with what I see in a disassembler of milcore, there still is a disparity between what WPF uses and what milcore CAN do.I dunno. I’m going to continue to sulk in the corner, but I’m not gonna hold my breath.-Jer

  4. I think all the wonderful juicy stuff lies inside PresentationCore!System.Windows.Media.Composition and mainly the internal class DUCE.

  5. I’m on board here as well. To play devil’s advocate, think how much more effort would it have taken to document the MIL to the level that the rest of the current APIs provide. We’d probably still be waiting for Vista.Have you looked at System.Windows.Media.Composition (the internal .NET wrapper around MIL)…it’s a beast.Anyone up for some spelunkin? 😉

Leave a Reply