I've been writing test programs, just to get the hang of Direct3D. So far, they all run great, except for one problem in common with all my tests.

All my test programs run in Windowed mode, and the rendering calls are kept in a secondary thread (not the main thread with the message pump) that runs in a continuous loop until the program quits or an error is generated. Everything works just as expected, when I move the window, resize it, minimize it, maximize it, and so on... with one exception.

Whenever the rendering portion of the window is completely hidden, either occulded by other windows or when the window size is adjusted so the rendering area isn't visible, my system suddenly slows to a halt. This does NOT happen when the window is minimized, or when it is partially concealed; only when it is normal or maximized, but completely concealed. No errors are reported, no system warnings are issued. My computer simply stops responding for several seconds, then runs normally for several seconds, then stops responding again, and this behavior continues until the D3D-using program is uncovered or enlarged (or closed).

Removing the rendering functions from the secondary thread, and putting them in my message handling process so they are only executed when WM_PAINT messages are generated seems to prevent this, but for my purposes the window needs to be continuously updated, not just when a WM_PAINT command is issued. Does anyone know if it's something I'm doing wrong, or if this is a problem in the D3D functions that needs to be compensated for by not rendering when the window is concealed?
Posted on 2003-08-01 20:54:08 by Tatterdemalian
Afternoon, Tatterdemalian.

I've never found a real need for separate threads in proggys.

Try having your message-pump something similar to this:


.WHILE 1
INVOKE PeekMessage, ADDR msg, NULL, 0, 0, PM_REMOVE
.IF eax != 0
.IF msg.message == WM_QUIT
INVOKE PostQuitMessage, msg.wParam
.BREAK
.ELSE
INVOKE TranslateMessage, ADDR msg
INVOKE DispatchMessage, ADDR msg
.ENDIF
.ELSE

INVOKE Render

.ENDIF
.ENDW


That code will make your proggy do the rendering whenever there *isn't* a windows message to handle (i.e. it renders during idle-time).

Cheers,
Scronty
Posted on 2003-08-01 21:36:53 by Scronty
I used to use that kind of message pump, but it had the same problem, and what's more, it also made the system start freezing when the window was minimized as well. I went to a multithreaded format in the hopes that it would work better, but it still suffers problems when the window is covered.
Posted on 2003-08-01 22:53:43 by Tatterdemalian
Curiouser and curiouser...

In an attempt to locate the cause of the freezing, I added some code that brought up a second window, which continuously displayed the name of each D3D function just before it is executed. This way, when the system froze while the rendering window was covered, it would show in the second window which function the system was hanging up on. The second window just used GDI functions to display text (the name of the functions).

Here's the weird part... while the second window was on the screen (visible), the system ran normally, even while the render window was completely covered. When I covered both the render and diagnostic windows, however, the system started freezing up again.

I know there's something I've been doing wrong. Is there anyone out there who has had this happen to them before, and knows what causes it?

Should I post this to one of the other forums? I don't think it's a D3D problem, it's probably something I did elsewhere that's making the system jam.
Posted on 2003-08-02 20:42:42 by Tatterdemalian
Afternoon, Tatterdemalian.

You might as well stay in this forum, since it's only in game programming that you'd find a need to modify the messagepump.

The only times I've come across a problem like yours, is when I had Windows Media Player or Real Player running.
You got any program running that also uses DX?

Cheers,
Scronty
Posted on 2003-08-03 05:15:42 by Scronty
I think I solved it... apparently it was something in DirectX 9.0 that was causing the freezing. Upgrading to 9.0b seems to have fixed the problem.

Sorry to have bothered you, turns out it was a driver issue after all.
Posted on 2003-08-03 21:17:33 by Tatterdemalian