C# WPF OnPaint method alternative?

Question

In C# WinForms whenever making a small game here or there, I would write up a quick class that was a subclass to System.Windows.Forms.Panel and in the constructor, setting DoubleBuffered to true. Then you could override the OnPaint method to display game elements. I've done this for 2 or 3 years now, but I'm really trying to embrace WPF and XAML, I really like it for regular application layouts. What equivalent is there to doing this in WPF?

Answer 1

Not the answer you seek, but: you shouldn't use WPF for games. Stick with Forms (which won't be dumped by MS, since WPF isn't superseding Forms) or try XNA if you want to go to the next level.

---

UPDATE: I answered the question very quickly yesterday, because I was in a hurry and because I also looked into WPF in order to do games, so I didn't wanted to left the OP without the proper answer.

Here is the deal:

WPF goal is to simplify rich UI development. First, MS understood that Forms way of coding mix behavior with presentation. This is bad, both for application design as for maintainability. Besides, in Forms, everything has to be coded; The library itself does very little for the user. For example, if you want a button that has a different look, you have to override its Draw method and then, somehow, draw whatever graphic that represents it.

With WPF, behavior is separated from the presentation. For example, what is a button? In windows, we know it to be a box with rounded corners, but look around... your mouse scroll is also a button, even though it looks nothing like the Windows default button. Being a button means having a specific behavior (clicking, mostly), not looking like a box. With WPF, this is very simple. You define a button and then use, say, an image or a text, to present it to the user.

All this comes at a cost, of course; for example, WPF is slower than Forms. Games need to be quick and try not to waste resources. In games, every behavior tends to be coded (not the UI, of course), every presentation is customized (a 2D graphic or a 3D object), so you will have to do a lot of coding anyway. So you are using an expensive technology but throwing away most of its benefits.

But I'm no specialist. You can check this blog, where an ex-Microsoft employee tried, for almost two years, to use WPF for games. And he concludes:

You've probably noticed that the blog hasn't been updated in a while. WPF performance just doesn't seem to be there for serious games, and I've thrown in the towel and will work on games using XNA. I just don't think it's worth fighting the WPF framework...

From there I've drawn most of my conclusions.

Answer 2

UIElement.OnRender.

To be used sparingly; it's not as efficient.

It's a bit of a paradigm shift.

Answer 3

There are a few Containers to display stuff. That one which you would like to use is a Canvas(the only one with coordinates system) some more details

The key is what kind of game you are up to. Using xaml it could be a some basic app-like game (basic drawings and so on). For something more consider using XNA. The advantage of xaml is that it's easy to interact with user via handlers, f.e it's simple to write a string onto screen which is a bit harder for XNA. Also using xmal u could make a game for IE (XABP), Windows Phone and Silverlight.

What you were doing with form is a bit of loop-style game.

Update(); Paint();

and this fits XNA more. But if you want to use WPF and Xaml use Canvans and LayoutUpdate Handler.