Answered by:
System.Windows.Forms.Control in WPF 3D Land

Question
-
Hi,
I have a legacy 2D custom control (a System.Windows.Forms.Control derived control) that I want to be able to put in 3D space using WPF 3D ... and still be able to interact with it.
Now, I was thinking that:
a) that I could use a WindowsFormsHost and go the .NET 3.0 route with Interactive3DDecorator & InteractiveVisual3D from 3DTools, or ...
b) that I could use a WindowsFormsHost (from WindowsFormsIntegration) and Viewport2DVisual3D from .NET 3.5
Given that, I tried quickly plugging (using WindowsFormsHost) this legacy 2D custom control into both the 3DTools' Channel 9 sample and Greg Schecter's ParallaxUi demo. Both didn't work too well.
Is there a basic reason why this isn't working? That is, is it even possible to use WindowsFormsHost in this manner?
Thanks,
Cory
Tuesday, September 4, 2007 10:51 PM
Answers
-
Think of a WindowsFormsHost as a big fat square that sits on top of everything WPF. It is not rendered within the WPF compositor, so you can not put it on 3D or do any transformations. There is a good explanation here: http://msdn2.microsoft.com/en-us/library/aa970688.aspx
We have started a codeplex project to overcome these issues, but there is a bit of a performance hit. You can adjust the FPS of the painting to lower the CPU tax too.
http://www.codeplex.com/WPFWin32Renderer
It's not perfect, but might work in some situations.
Wednesday, September 5, 2007 1:18 AM -
Well, I did spend some time hooking my System.Windows.Forms.Control into the sample application/source code that exists out at http://www.codeplex.com/WPFWin32Renderer.
The good news is that my Win32 based control rendered into WPF 3D land ... and I was even able to interact with it!
But the bad news is that it was a hog on the performance side of things. It chews up CPU cycles like there is no tomorrow ... even when we throttle down the FPS rate according to Jeremiah's suggestion above. For us, this is definitely not a viable solution with the performance as it exists currently.
However, I'm definitely going to keep my eye on this project, and will especially take notice of any performance improvements.
In fact, one idea that we had here, was to take advantage of the inherent change notifcation structure built into our specific System.Windows.Forms.Control. That way, we could manually force an update instead of relying on a timer that fires every so many milliseconds. But ... that would probably not work if the user dragged a different window over the top of the window that has the Viewport3D in it.
But, given my small experiences here, it might make more sense to just port the System.Windows.Forms.Control into WPF ... then I should have none of these problems ... or at least I have a different set of them. <grin>
Wednesday, September 5, 2007 7:19 PM
All replies
-
Think of a WindowsFormsHost as a big fat square that sits on top of everything WPF. It is not rendered within the WPF compositor, so you can not put it on 3D or do any transformations. There is a good explanation here: http://msdn2.microsoft.com/en-us/library/aa970688.aspx
We have started a codeplex project to overcome these issues, but there is a bit of a performance hit. You can adjust the FPS of the painting to lower the CPU tax too.
http://www.codeplex.com/WPFWin32Renderer
It's not perfect, but might work in some situations.
Wednesday, September 5, 2007 1:18 AM -
Thanks for your reply.
I ran into your codeplex project a couple weeks ago ... and thought, I wonder if this would help me out ... but I hadn't yet got to the point of hooking stuff together.
Guess it's time to see if WPFWin32Renderer works for me or not ... again, thanks.
Wednesday, September 5, 2007 1:10 PM -
No, it's not possible. You will never get this kind of functionality working properly, win32 just wasn't meant to be used in that way. Windows Forms is based on win32.
- Proposed as answer by angelicc Tuesday, July 29, 2008 1:25 PM
Wednesday, September 5, 2007 2:54 PM -
Well, I did spend some time hooking my System.Windows.Forms.Control into the sample application/source code that exists out at http://www.codeplex.com/WPFWin32Renderer.
The good news is that my Win32 based control rendered into WPF 3D land ... and I was even able to interact with it!
But the bad news is that it was a hog on the performance side of things. It chews up CPU cycles like there is no tomorrow ... even when we throttle down the FPS rate according to Jeremiah's suggestion above. For us, this is definitely not a viable solution with the performance as it exists currently.
However, I'm definitely going to keep my eye on this project, and will especially take notice of any performance improvements.
In fact, one idea that we had here, was to take advantage of the inherent change notifcation structure built into our specific System.Windows.Forms.Control. That way, we could manually force an update instead of relying on a timer that fires every so many milliseconds. But ... that would probably not work if the user dragged a different window over the top of the window that has the Viewport3D in it.
But, given my small experiences here, it might make more sense to just port the System.Windows.Forms.Control into WPF ... then I should have none of these problems ... or at least I have a different set of them. <grin>
Wednesday, September 5, 2007 7:19 PM