Skip to main content
GameDev.net gamedev.net
🔒 Locked

[MDX] Rendering to Control created in other thread

Started by Michael Tanczos Jul 31, 2009 at 11:27 PM 3 replies 2.1k views
Original Post
Michael Tanczos
Michael Tanczos
First, I'm using C# MDX. I'm not sure what the general strategy here for rendering is. I created my render loop in a separate thread and I seem to be able to render to the Direct3D device I created just fine. I'm using the same device to present to additional windows (controls) in lieu of using swap chains. However, the device only seems to present when the control window is created within the same thread. My question is two fold. First, when I'm rendering to the window I created within the render loop thread I get a consistent busy mouse icon when I mouseover the window. I cannot interact with the window in any way. Any idea what causes this? Is the window not handling events? Second, what would the more appropriate rendering strategy be? I'm attempting to render a series of composited textured quads to one window, and the individual layers that make up that composition to another window by using viewports. I'm not sure how to handle the thread interaction here.. should I have not created the control in the render loop? If I don't I can't seem to get rendering to it to work. Thanks in advance for anybody who can assist. - Michael Tanczos
Washu
Washu
Well, few things:
1. MDX is deprecated, EOL, and buggy in many ways. You should probably be using SlimDX.
2. You should hook the OnIdle event of the Application object if you need continuous rendering, then PInvoke (see the SlimDX sample framework) PeekMessage and simply break out of your Idle renderloop when a message arrives. This will ensure that:
a) Messages are processed ontime
b) You always get to know when it's free to render.

Secondly, avoid rendering to form controls from another thread. It doesn't behave well because Win32/GDI was not designed with threading like that in mind. Again, it's buggy and can cause strange behaviors. Use swap-chains as well to render to multiple windows/controls.
In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.
Michael Tanczos
Michael Tanczos
Perfect. This worked very well. If it's not too much trouble, a followup question? I have a multiple monitor setup. When I move one of the windows to a secondary monitor the rendering for that monitor slows to a crawl. Now both windows on each monitor are being rendered with the same device.. if I move the window back to the main monitor it continues to be fast. Do I need to use swap chains to make it possible to do multi-head monitoring?

- Michael
Washu
Washu
Typically each monitor is represented by a different device. You'll notice this in games when you get to select the adapter that it will list two. One for each output on your card that is active.
In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.
Michael Tanczos
Michael Tanczos
Is this possible then? I want to have a windowed form on one adapter, and a windowed (or fullscreen) form on a second adapter. The same device should be able to render to them both. Could I render to an offscreen plain surface perhaps and use that between devices?

You know what, since my problem that this topic was for was resolved I'm not going to piggyback any more questions on it. Instead I'll create a new thread dedicated to the different issue. I think that would be a better approach if people want to use this post in the future.

- Michael

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.