WPF Hackery!

Silverlight 4 Hack: Use Native/Desktop CLR Without COM Registration

Fri, 05 Feb 2010 03:18:05 GMT

WARNING: Information and code here can easily be abused. Please do not use it as a crutch in application planning, but more for utter despair or experimentation. Thus I wrote this blog post from that perspective.

Silverlight 4 + OOB + Elevated Trust gives us the ability to use COM. That would be extremely useful (vs. really useful), except we cannot use just any COM class. It has to support IDispatch (COM automation). It also has to have a ProgID associated to it. That leaves you still with quite a few built-in COM objects to work with, as Justin document's quite well here. What about running our own native or .NET code? One would have to register a COM object first, which requires administrator rights. That’s no fun for an end user! Optimally, it would be nice to be able to add your desktop CLR objects as resources to your XAP, and from Silverlight code, be able to instantiate and use your Desktop .NET classes. This is a hack to do just that.

Huh? What does the hack do?

Let me explain it in code.

/* Create our Desktop .NET helper */

dynamic fullDotNetProxy = fullDotNetProxy = ComAutomationFactory.CreateObject("ClrProxy");

/* Have our .NET helper load up our .NET assembly we extracted from our SL app resources */

dynamic assembly = fullDotNetProxy.GetAssembly(m_assembliesPath + "\\Inject.Test.dll");

/* Get our .NET Type */

dynamic testClassType = fullDotNetProxy.GetDotNetType(assembly, " Inject.Test.TestClass");

/* Create an object instance of our .NET type */

m_testClass = fullDotNetProxy.CreateInstance(testClassType);

/* Run our RunMe method on our .NET object */

m_testClass.RunMe();

Hold on a second! Where did “ClrProxy” ProgID come from? That’s not built in to Windows! I thought we didn’t have to register anything?

That’s where it gets complicated. Or hacky. We actually use COM interop to inject a native DLL into the Silverlight process. Once injected we override some native methods that Silverlight uses internally to instantiate COM. Our hooked methods listens for when a ProgID of “ClrProxy” is requested and then goes into action.

Not bored yet. Explain further.

Use WScript.Shell's "Run" method to execute rundll32.exe
Rundll32.exe executes my native.dll.
My native.dll get's the process Id and hWnd of the process that started it up (The Silverlight OOB Process)
The native.dll is injected into the Silverlight process's and hooks it's WndProc
The Silverlight process the hooks two methods in ole32.dll used by all windows applications to create COM objects
In Silverlight code, every time you call ComAutomationFactory.CreateObject("ClrProxy") my hook will detect it and return a .NET 2.0 CLR object. The real CLR proxy class is very simple and I only expose some reflection routines so I can load up any .NET Dll. Silverlight facing code still uses the dynamic keyword.

So where do I get the code and how do I run the demo?

How to run the demo:

Load up the project. Set the Silverlight web app as start up.
Run the project, and install the SL app OOB.
Click the only button on the window and watch SL talk to a .NET class w/o any registration

I left all the compiled dlls in there in case you were having trouble compiling the C++.

Here is the code:

Silverlight.Mainline.Example.zip

Silverlight and Desktop .NET Integration

Wed, 13 Jan 2010 06:38:03 GMT

No matter how you feel about Silverlight 4’s COM interop, it does add an escape hatch out the sandbox when you are running an out-of-browser application. I don’t see many .NET folks getting excited about having to wipe off the dust on their C++ compiler and learn COM all over again for the first time.

Here I want to show a way of making a COM object in pure desktop .NET and using it from Silverlight. This stuff has been around since the dawn of .NET, but it may be a little more obscure to others who have never done it.

Step 1:

Create a new Silverlight 4 application and add a desktop .NET class library (show here as the “COMObject” project)

Step 2:

Setup your Silverlight application to support out-of-browser support AND don’t forget about the elevated trust!

Step 3:

Get your desktop .NET class library ready for COM. In the project settings of the class library set your stuff up like this:

This setting bellow is NOT required, but is there for convenience so you don’t have to manually run “regasm” to register your assembly. YOU MUST RUN VS2010 WITH ADMINISTRATOR RIGHTS IF YOU HAVE THIS OPTION!

Step 4:

In your desktop .NET class library add a class like this:

[ProgId("SilverlightCOM.Example")]

[ClassInterface(ClassInterfaceType.AutoDual)]

[Guid("5267F53A-0E5F-490A-A891-FFE8B3840D72")]

public class ComClass

    [ComVisible(true)]

    public void RunMe()

        System.Windows.Forms.MessageBox.Show("Hello from .NET via COM!");

Make sure to give it your own GUID and ProgId!

Step 5

In your Silverlight project add some code like this:

dynamic comClass = ComAutomationFactory.CreateObject("SilverlightCOM.Example");

comClass.RunMe();

Step 6:

Run your Silverlight application and install it out-of-browser and you are done!

Conclusion:

Yeah its that easy. If you need to manually register your assembly manually, use regasm!

The source code

SilverlightCOM.zip

Render Silverlight in WPF – WPF SilverlightViewport

Mon, 21 Dec 2009 03:06:07 GMT

A hobby project I have been working on, to clear my mind of the daily grind, is a Control that lets a developer host a Silverlight application to WPF.

A good kept secret is there is complete COM API for hosting Silverlight outside the browser. There is even sample C++ code here. The problem I found with all of these was everything assumed you are rendering to Win32/Windowed. This is not the kind of thing we want in a WPF application. Airspace restrictions are for weenies.

I had remembered that Silverlight DOES infact support windowless. That given, I wrote a host in C# to load Silverlight windowless and had it render to my own GDI bitmap, instead of the screen. That worked well, but CPU usage was high and I didn’t get any alpha transparency. After some more research I found that the native SDK supports rendering to an ARGB buffer! After some more nasty, dirty native interop, I got it working with alpha transparency…and performance was much better.

I did start out using the WriteableBitmap, but eventually moved over to use InteropBitmap and performance got even better!

Anyways, there’s still a lot of work to be done, but I’m excited enough about it to show it off now.

Try it out at: http://silverlightviewport.codeplex.com

Update: I also want to thank Koen Zwikstra, for his project helped me prototype the original code. I’ve since rewrote everything, but you may find some things similar. This is why ;)

How to get access to WPF’s internal Direct3D guts

Sun, 06 Dec 2009 08:21:15 GMT

This one isn’t for the faint of heart, but if you are a Direct3D guru and always wanted some more low level access…here is a good start. This hack does a overwrites IDirect3DSwapChain9::Present method in memory to hook into the call WPF makes. In that hook, I also pull out the IDirect3DDevice9 pointer.

What can we do with this? Well for one, it would be possible to render WPF to a texture in a Direct3D scene. You can also fiddle with the WPF rendering process. And if you are really tricky, you can probably even do something even more amazing.

Given the time, I’d like to make a few examples, but for now, here is what I got.

You need the DX and Winders SDKs

WPFD3Dhack.zip

Direct3D 10/11 & Direct2D in WPF

Fri, 27 Nov 2009 19:22:19 GMT

For a while, I’ve wanted to tackle getting the newest Direct3D technologies to interop with WPF. Direct3D 10/11 and Direct2D all have very cool usage scenarios that are just impossible with the WPF API.

So far the only solutions I have seen to interop WPF and it’s cousin D3D technologies was to use hWnd interop. If you gotta have airspace restrictions, why even bother? Nobody really wants a hot, steamy, always-on-top hWnd hovering over their super cool WPF interface.

So how do we render D3D10/11 and D2D into WPF w/o airspace issues? We only have a D3DImage class that supports Direct3D9. Well the fine people of the WPF team informed me that a IDirect3DDevice9Ex, which is the recommended device to use with D3DImage in Vista/7, supports sharing resources between devices (and processes too if you care). We can create a shared render target on Direct3D10/11, then pull it in via an intermediate IDirect3DDevice9Ex device. No copying required! This resource we pull into 9Ex, can then be sent to the D3DImage for high performance rendering. I have not benchmarked anything, but just eyeing CPU performance, it does not seem to have any extra overhead in sharing the resources. Performance seems to be similar (if not the same) to using D3DImage with 9Ex and unshared surfaces.

I’ve created a D3DImage subclass to add support for D3D 10/11 render targets (Texture2D). Usage is simple:

   1: /* Set the back buffer, which is a ID3D10Texture2D pointer */

   2: m_d3DImageEx.SetBackBufferEx(D3DResourceTypeEx.ID3D10Texture2D, pRenderTarget);

One caveat is the D3D 10/11 render targets must be created as D3D10_RESOURCE_MISC_SHARED. The other caveat is I don’t handle lost devices (which only happens in a few situations with 9Ex, like driver being upgraded) just yet so I don’t recommend using this in production at the moment.

Also the D3D10 scene code is very sloppy and was pieced together from other samples. It’s also in C++, but I’ll do some managed examples later on.

To compile make sure you have the latest DirectX SDK and Windows SDK!

Interop.D3DImageEx.zip

Channel 9 Interview

Mon, 19 Oct 2009 21:57:43 GMT

About a month or so ago, I did an interview with Brian Peek (of much fame, ie WiiRemote .NET lib) to show off my WPF MediaKit project. Today it went live! This is my very first interview…on camera or otherwise.

Mad props to Brian for having me! And many thanks to the Coding4Fun team!

Anatomy of an MVVM Application or How Tards Like Me Make MVVM Apps

Tue, 13 Oct 2009 20:16:57 GMT

This article is a continuation of my “MVVM for Tarded Folks Like Me”. The aim here is not to teach the basics. There’s plenty of information on that out there. Even a tard should be able use the Google. My general intention is to give some guidance on hurdles that any developer who doesn’t have 1500ccs of brain matter might come across while learning how to develop an MVVM application.

I believe bullshit information to be a major hurdle in making well designed MVVM applications. So I wanted to kick this one off with my favorite myth…

Disclaimer: I’m going to speak mostly in the context of Silverlight from here on. Why? I want to talk least common denominator. There’s just so many ways to do things in WPF, I can’t and won’t cover them all. In any case, all concepts here are transferable to WPF. This is also where I get into style and opinion, so it’s going to be quite subjective. It may even piss some people off. Great!

“MVVM is an Overcomplicated Turd”

No, your code is. I can make this counter-claim with a level of certainty. Because I’m a pompous, MVVM-advocating prick? I don’t think I am, but that’s not really for me to say. In my previous article, I break MVVM down to what it is [for WPF/SL] at the core. It’s binding to a class that specifically deals with data for the UI. If that’s too complicated, research it some more. You are of reasonable intelligence. I believe in you.

Where MVVM starts to get complicated, is when you start using other patterns to help out with your MVVM-fu. This is when you feel the need to pass some event or data across the View/ViewModel barrier. It gets “complex” when you want one ViewModel to communicate with another, even though your VMs don’t have direct reference. One accepted practice is to use commanding for your View to talk to your ViewModel. Use a mediator to get your ViewModels to talk in a loosely coupled manner. If you want to see how to use commanding and a mediator, check out Laurent Bugnion’s MVVM Light library. He’s got implementations of both. To better illustrate my point, lets look at how many patterns are supported under Prism. There are at least 13 other patterns NOT MVVM dependant. That’s quite a bit of non-MVVM for what some folks label as an “MVVM Framework”.

There is a great post on Silverlight.net that I recognize as the epitome of MVVM gone bad. It’s MVVM perversion. It’s quite long, so I understand not reading all the way though, so I’ll paraphrase.

JFalcon is not happy and we end up sympathizing with him. We feel bad for his situation. He’s a victim. His architect, who does sound like an MVVM-purist prick, has him developing a numeric spinner control. His requirements were to create a view-model for this control and implement commands to handle the up/down clicks for the spinner.

If that last sentence didn’t raise any flags for you, well don’t worry because it certainly would not have when I started MVVM. “Isn’t this how you do MVVM apps?”, the green-eared, tarded developer might say. HELL NO! Let me explain further…

A View is a Control, a Control is a Control. A Control is Not a View? |or| Yet Another Stupid Programming Analogy

Let’s define what a view is. It’s your “Presentation”, what you “see”, right? Yes! So a Button is something I can see. That’s a view too! No! That’s a control. Before I confuse you (and myself) any more, lets make a real-world analogy. One of those contrived comparisons that fall apart if you look too deep. Maybe something about a car…or a mammal…or…I know!

You’ve all had to sit through a play before, right? Maybe it was Nutcracker or Phantom of the Opera, Lion King on Ice…doesn’t matter. If the answer is “yes”, well I’m sorry, I hate the theater too. But at least you may get where I’m going with this. The point is you have a script, a stage and some actors and props. The actors, they perform on the stage. They perform based off a common script.

Lets bring it back to that analogy I was promising. A view is like a stage. It brings all the actors, or CONTROLS, together. The controls perform based off a script or ViewModel.

Can I have another view within my view, side-by-side with the actors/controls? Yes! But I didn’t want to confuse my theater comparison just yet. But do realize that a view inside a View is ultimately how a non trivial application is composed, but for the concepts I’m dropping, a view should see any contained view as a Control.

Here are some ground rules that I use when deciding if I need a control or a view. I am no authority on any of this, and even though I talk about my rules…I have broken them all in my applications.

You want to make a control (actor) when:

Anytime you need to use the VSM or animations. I don’t believe you should ever directly use the VSM (ie give your View visual states) or animations in the View. This sounds extreme. I know. I thought so too at first. My reasoning is a View’s purpose in life is to give the controls a place to perform, and provide a script (ViewModel/Data). It should not be concerned with a Visual State [Manager]. You should not have to build extra infrastructure for you VM to tell your View to change states, nor should you be required to have a direct event handler in your code-behind to change states of your View. “But I want to animate my controls on my view. The VSM works so well and it’s not a big deal having some code-behind.” I can’t argue there, and this is not a hard line rule I’m proposing. This is more of a rule I’m suggesting. I handle the “animation” problem with either creating a control, a panel, etc, that handles the animation. Take a look at the TransitioningContentControl. This is a great example of a control that you can style, use the VSM on, include it in your view.
When the data required for the actor to operate is not domain specific. Think about a . It takes a collection of data. It doesn’t care if the data is a list of monkies. If we need to format our UI based on domain specific data (monkies), create a copy of the control’s style, maybe inside your view, and format away.
You need to make a wrapper for other controls
It’s so atomic and simple, you have no choice but to make it a control.

You want to make a View (stage) when:

You need some controls working in concert and you need a way to delegate domain specific data to them.
You need to take user input and send it to code for processing against your application’s domain logic.

In summary, I treat the view as a UI mediator (and layout provider, style setter and maybe resource holder) between data and other UI. “Other UI” being controls. Got it?

Getting the Most Out of a Control

I just talked a butt load about controls. I wanted to cover them a little more in detail. One of the things that really changed my XAML life was the concept of lookless controls. It is one of the most powerful parts of WPF/SL, but yet the MOST unused features by folks new to WPF/SL. You create a control that has no XAML associated to it. You define “PARTS”, which are sort of like defining a contract between your lookless control code and it’s style. When a style is applied to your control, you pull reference to the specific elements you want to manipulate in code and/or hook into events on these elements. Generally when creating a lookless control, we create a default generic template. In my practice, this default template is made for the designer of Blend. So they have a literal and visual understanding of what my control is and does. This generic template exists in a special place in your project. Themes\generic.xaml, which is just a ResourceDictionary.

MVVM for Tarded Folks Like Me or MVVM and What it Means to Me

Sun, 11 Oct 2009 03:36:07 GMT

MVVM has been a trending topic lately. And why shouldn’t it be? People want to build great WPF/SL applications and want guidance on how to build them using the framework’s strengths. If you are anything like me, you started your WPF/SL career, learning the framework classes and hierarchy. You learned XAML, triggers, storyboards and animations. You even hobbled together something that looked mind blowing, but the code was a monstrosity. Where do you go from here? How do you leverage all this separation of UI and biz-code that was promised in WPF?

I’m going to go out on a limb and make a wild assumption. I believe the majority of people that are trying to learn MVVM [and are having trouble] have never practiced any sort of UI application pattern. Maybe they dabbled in MVC/MVP. Maybe they studied the GoF patterns in school. Why do I assume this? Well because that describes myself and it describes lots of other developers I’ve interacted with. Not very scientific reasoning, but I’m going with it anyways. Because of this lack of general experience, MVVM tutorials and write-ups can be difficult for many developers. Some of these developers will no doubt take MVVM as a very strict pattern and do not deviate from what their perception of MVVM purity is as not to upset the MVVM gods. So that said, the rest of this write up I’m going to try to start from square one. As if I was talking to myself years ago. Layman as #%$@.

Beginner’s MVVM Challenge #1 |or| Takin’ You Down to MVVM Town

So we want to begin our journey into MVVM town by way of Bindingopolis. Our first web search brings us to a tutorial talking a bunch of mumbo jumbo about models, views and view-models. Usually you get a good description of what each is in concept, which is cool, but we also want to know what is it in CODE?

A model is a class that has your data. No magic here.

class Model{    public string Name { get; set; }    public string Address { get; set; }}

A view is, for the sake of explanation, is a UserControl. It’s a kind of like a mullet. Except its a party in the front, code in the back.

/// /// Interaction logic for View.xaml/// public partial class View : UserControl{    public View()    {        InitializeComponent();    }}

A View-Model is, again, just another class. This is where your View (aka UserControl) will get it’s data. It’s a data abstraction of your View. So if you view needs some data, this is where it gets it. If values need to be converted/formatted, this would be a good place to do it. Take special notice of the INotifyPropertyChanged interface.

class ViewModel : INotifyPropertyChanged{    private Model m_model;     public ViewModel()    {        m_model = new Model();    }     public string Name    {        get { return m_model.Name; }        set        {            if (m_model.Name != value)            {                m_model.Name = value;                InvokePropertyChanged("Name");            }        }    }     public event PropertyChangedEventHandler PropertyChanged;     private void InvokePropertyChanged(string propertyName)    {        var e = new PropertyChangedEventArgs(propertyName);        PropertyChangedEventHandler changed = PropertyChanged;        if (changed != null) changed(this, e);    }}

The ViewModel class is really up to you how you want to design it. The INotifyPropertyChanged interface allows us to update bindings (more later). It’s accepted practice to make a base class for the ViewModel. Some folks inherit from DependencyObject and make dependency properties for things in their view model. Don’t do this. Those people are sadists.

Beginner’s MVVM Challenge #2 |or| A Menage a Trois That Won’t Get You in Trouble

So how do our three players, the Model, View and ViewModel, work together? What sort of witchcraft must we implement? DataContext (again, for the sake of simplicity). Take a look at your View’s (UserControl) class hierarchy. You’ll see FrameworkElement in there. This has a property called DataContext of type object. When you set the DataContext, it will propagate down the tree. So to answer the question of how these all fit…Your model is loaded from where-ever, a data base, a file, etc. Your ViewModel gets your Model and exposes it’s data to your View. Your View gets access to your ViewModel from, wait for it…the DataContext.

Consider this from our code snippets above:

myView.DataContext = new ViewModel();

And the XAML for the “View” class.

<UserControl x:Class="WpfApplication3.View"    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"    Height="300" Width="300">    <Grid>        <TextBlock Text="{Binding Name}" />    Grid>UserControl>

So you see, we explicitly set the DataContext. We also setup a binding in our View’s XAML. WPF/SL will automatically look at the DataContext via reflection and pull out value for the “Name” property. If we write code in our ViewModel to change the value of the “Name” property, it will automatically be updated in our UI via the binding. This is the purpose for INotifyPropertyChanged.

If we want to update the value in the view model from the UI we’d do something like this:

<TextBox Text="{Binding Name, Mode=TwoWay}" />

Now when we run this, the the value of the “Name” property will be in a TextBox. When you edit the value (and the TextBox loses focus), the view model’s Name property will be updated.

I would like to mention that getting the View and ViewModel together is a topic in itself. Some people explicitly set the ViewModel to the DataContext. Some people set it in the XAML. Some people just include the ViewModel as a and do StaticResource bindings to it. Some people use dependency injection and some use a service locator pattern (or both DI and ServiceLocator). All of these have it’s pro’s and cons. It all depends what is important to you.

So now all this raises another question: Why even bother? I can just load my model from code-behind and fill in the properties myself.

We have successfully partitioned our application. A designer can edit the Views XAML in Blend without too much fear of breaking any business logic. They can design without Blend crashing on them. Your code now has a separation of concerns, making extensibility, testing and maintenance much less involved than stepping through thousands of lines of interconnected, circular dependant spaghetti. Don’t get me wrong, you can still write shit code in MVVM, but MVVM is a good start in avoiding shit code.

Beginner’s MVVM Challenge #3 |or| MVVM is a Mole-hill, Not a Mountain.

In my opinion, the last couple pages, this is all MVVM is. It’s NOTHING more.

“But Jer”, you say, “How do I make my View do X with the ViewModel? How do I make my ViewModel do Y to the View? This can’t be IT. There’s gotta be more to MVVM.” Yes there is more, but not to MVVM. There are other patterns you should be aware of to assist you in MVVM. Patterns like commanding (baked into WPF, solutions for SL), mediator and *gasp* dependency injection. There’s other facilities baked into WPF and Silverlight that can further assist, such as the ItemsControl and data templates. I will, in a later post, talk more deeply on these subjects in an article named “Anatomy of an MVVM Application *or* How Tards Like Me Make MVVM Apps”.

Some more breaking changes in MediaKit

Mon, 05 Oct 2009 06:57:51 GMT

The code in the WPF portion of WPF Mediakit was starting to get a little spahgetti-ish. This was mostly do to me trying to handle as many usages of this control as possible and also dealing with the async nature of MediaKit. It has to support the XAML parser and code-behind. But what if you had properties set in a certain order in the xaml, but you put them in another order and everything breaks? What if you set the source property and start playing in code-behind, then you put it in the visual tree and it executes the “LoadedBehavior”? Things just weren’t predictable enough.

I now use the ISupportInitialize, which is implemented in FrameworkElement and has overrides for BeginInit/EndInit. Now the code is much cleaner and further additions won’t be so confusing and buggy. The idea behind this usage is the xaml parser will automatically call the BeginInit/EndInit when the control is loaded, therefore within the control, we can ensure the properties are set in the correct order and we have some predictability when using the code from code-behind. If you just mainly use the built in MediaKit controls, things should work, but if you use the BeginInit/EndInit when starting to initialize the control and when you are done initializing it. After the EndInit is called and properties are set, the next property changes will go directly to the DShow COM thread.

Here is an example of how to create a MediaUriElement from codebehind.

   1: var player = new MediaUriElement();   2:     3: player.BeginInit();   4: player.Source = new Uri(GetRandomFileFromDirectory());   5: panel.Children.Insert(pos, player);   6: player.EndInit();

As always, if you have any issues, contact me directly or leave a message on codeplex.

WPF MediaKit Updates

Wed, 30 Sep 2009 06:30:52 GMT

I haven’t had much time the last few months, but in my spare minutes I’ve been doing some work with the MediaKit. Mostly to solve some very outstanding issues and annoyances. The biggest one was a reported memory leak and another was a problem with reentrancy of the message pump. Both were somewhat related. Both had to be fixed. Why would you want to dump the leak MediaElement for something that leaked just as bad or worse?

Reentrancy? What?

In the WPF MediaKit, I was using a new WPF Dispatcher instance and thread. The reason for this was:

WPF’s UI thread runs STA. We might want to run MTA COM apartments for our COM objects
DirectShow has blocking calls. We never want to block the UI thread. Maybe that was ok in Winforms. Sure is not kosher in WPF any more.
I need a Win32 message pump, and WPF’s Dispatcher supplied that.
It’s very convenient. The API is familiar. It’s well engineered.

So what’s the issue with the WPF Dispatcher? Reentrancy! See, DirectShow uses the Win32 message pump to relay some messages, maybe handle automatically created render windows, fire events and what not. So lets say we tell our DShow’s Dispatcher to BeginInvoke(OpenFile) then BeginInvoke(Play). We’d expect (given equal dispatcher priorities) that OpenFile will execute, then finish. Then the dispatcher will execute Play, then finish. Imagine my surprise when I saw OpenFile() execute 1/2 of the method, then switch over to the Play method! Same thread in two places at the same time? Debugging DShow can be tough, but it shouldn’t be like quantum physics! What was happening is a call to DShow was dispatching a Win32 message, which was picked up by the WPF Dispatcher and executed, then the Dispatcher would execute the next delegate in the queue, which was something like Play(). Jaime Rodriguez and Dwayne Need were kind enough to explain this to me in gory detail. Apparently, the WPF Dispatcher interleaves the Win32 message pump and .NET delegates.

Fixing this was going to require creating my own simple dispatcher/dispatcher-object that does what the WPF Dispatcher does, just it doesn’t interleave Win32/CLR delegates. This fixed many issues off the bat. Specially that damned RaceOnRCWCleanup MDA! Also, you no longer need some stupid static factory class to create your WPF Dispatcher and initialize your COM player.

Memory Leaks! @#$%!

Running a simple loop of: Create MediaUriElement, assign a Uri, Play(), Close(). This would eventually show over 16,000 open handles after about half a day and well over a gig working set. Writing a new Dispatcher fixed quite a bit of my issues in this area, but spending some time with Windbg was really what revealed where the problem areas were. This still was not an easy process, considering the complexity of a managed COM API, running in .NET, using 3rd party filters, rendering in a D3D environment, interoping to WPF. It’s a jungle in there. I still want to monitor the leak area, but so far I’m ~~pretty~~ very pleased with it.

Not really a memory leak, but I wanted to cover a change in the MediaKit’s base classes. I have now modified it so the default “Unloaded” behavior is Close. As long as the Close is called by something, either automatic w/ the unloaded behavior, or explicit in your code. This needs to be called when you are done with any of the players. This will property shut down the dshow player thread. What was extremely tricky was the scenario of: What if you call Close, but then you set a property (ie the Uri “Source”) and tell it to Play(). The control won’t do shit anymore. I added a method on to my WorkerDispatcher called EnsureThread. This ensures the WorkerDispatcher has a thread. This is automatically called in the base classes’ Play() and Pause() protected virtuals.

Optimization

Turns out that creating too many IDirect3DDevice9s on lower end cards makes your app die. I now have one static shared IDirect3DDevice9 in the VMR9 allocator. This seems to work out great, but this limits us to MTA ONLY at the moment. In the future I will update the EVR to do the same, but also leave in the ability to support STA (which may take more work on my custom Dispatcher, WorkerDispatcher). This may be done in the future by setting a “UseSharedResources” flag.

If you are using WPF MediaKit now, there are breaking changes…but I believe them to be very minimal. Please test the newest code and let me know if you find any issues. I have not deeply tested any of the sample controls, like the DVD or Webcam controls, extensively but they will be next on my list.

WPF Hackery!

Silverlight 4 Hack: Use Native/Desktop CLR Without COM Registration

Huh? What does the hack do?

Hold on a second! Where did “ClrProxy” ProgID come from? That’s not built in to Windows! I thought we didn’t have to register anything?

Not bored yet. Explain further.

So where do I get the code and how do I run the demo?

Silverlight and Desktop .NET Integration

Step 1:

Step 2:

Step 3:

Step 4:

Step 5

Step 6:

Conclusion:

The source code

Render Silverlight in WPF – WPF SilverlightViewport

How to get access to WPF’s internal Direct3D guts

Direct3D 10/11 & Direct2D in WPF

Channel 9 Interview

Anatomy of an MVVM Application or How Tards Like Me Make MVVM Apps

“MVVM is an Overcomplicated Turd”

A View is a Control, a Control is a Control. A Control is Not a View? |or| Yet Another Stupid Programming Analogy

Getting the Most Out of a Control

I Hate Diagrams

MVVM for Tarded Folks Like Me or MVVM and What it Means to Me

Beginner’s MVVM Challenge #1 |or| Takin’ You Down to MVVM Town

A model is a class that has your data. No magic here.

A view is, for the sake of explanation, is a UserControl. It’s a kind of like a mullet. Except its a party in the front, code in the back.

Beginner’s MVVM Challenge #2 |or| A Menage a Trois That Won’t Get You in Trouble

Beginner’s MVVM Challenge #3 |or| MVVM is a Mole-hill, Not a Mountain.

In my opinion, the last couple pages, this is all MVVM is. It’s NOTHING more.

Some more breaking changes in MediaKit

WPF MediaKit Updates

Reentrancy? What?

Memory Leaks! @#$%!

Optimization

WPF Hackery!

Silverlight 4 Hack: Use Native/Desktop CLR Without COM Registration

Huh? What does the hack do?

Hold on a second! Where did “ClrProxy” ProgID come from? That’s not built in to Windows! I thought we didn’t have to register anything?

Not bored yet. Explain further.

So where do I get the code and how do I run the demo?

Silverlight and Desktop .NET Integration

Step 1:

Step 2:

Step 3:

Step 4:

Step 5

Step 6:

Conclusion:

The source code

Render Silverlight in WPF – WPF SilverlightViewport

How to get access to WPF’s internal Direct3D guts

Direct3D 10/11 & Direct2D in WPF

Channel 9 Interview

Anatomy of an MVVM Application *or* How Tards Like Me Make MVVM Apps

“MVVM is an Overcomplicated Turd”

A View is a Control, a Control is a Control. A Control is Not a View? |or| Yet Another Stupid Programming Analogy

Getting the Most Out of a Control

I Hate Diagrams

MVVM for Tarded Folks Like Me *or* MVVM and What it Means to Me

Beginner’s MVVM Challenge #1 |or| Takin’ You Down to MVVM Town

A model is a class that has your data. No magic here.

A view is, for the sake of explanation, is a UserControl. It’s a kind of like a mullet. Except its a party in the front, code in the back.

Beginner’s MVVM Challenge #2 |or| A Menage a Trois That Won’t Get You in Trouble

Beginner’s MVVM Challenge #3 |or| MVVM is a Mole-hill, Not a Mountain.

In my opinion, the last couple pages, this is all MVVM is. It’s NOTHING more.

Some more breaking changes in MediaKit

WPF MediaKit Updates

Reentrancy? What?

Memory Leaks! @#$%!

Optimization

Anatomy of an MVVM Application or How Tards Like Me Make MVVM Apps

MVVM for Tarded Folks Like Me or MVVM and What it Means to Me