Problem with MFC closing view using OpenGL driver

[robmar]

I´ve discovered that with an Windows MFC application, if you use the OpenGL driver, after the user closes the view window, there is a delay of about 5 seconds before the following call returns, leaving the GUI blank and unuseable, that cannot be easily explained:-

//doccore.cpp
void CDocument::OnCloseDocument()
{
...
pFrame->DestroyWindow();
---

This calls the view and document deletedoc, etc functions, which rapidly delete the Irrlich device (in about 100 mS in debug).

However, on exiting the MFC view´s destructor class, the thread that called DestroyWindow in OnCloseDocument does not return for about 5 seconds, blocking the GUI.

This behaviour is not replicated with the D3D driver.

I´ve carefully timed and stepped through all the destruction code for the entire application, and for some reason, there is a delay in returning from the view´s destructor, to MFCs message handling code, which leaves the windows GUI blank for many seconds.

Its sort of strange because the Irrlicht device is long gone, and not other functions in the application are called, so why the problem?

[robmar]

After some tedious single-stepping through MFC, my own code, Irrlicht code... my neigbours code... nothing shows!

The OpenGL driver, in contrat to the D3D driver, sets flags for the external window if it isn´t flagged as fullscreen mode to calculate the window size, which I think could be removed or controlled as an option, because some if not all users will have the external window inside their own container or client window, so maybe its not good to assume the Irrlicht window will have a border and menu, for example.

This is the line from the opengl driver:-

if (!params.Fullscreen)
style = WS_SYSMENU | WS_BORDER | WS_CAPTION | WS_CLIPCHILDREN | WS_CLIPSIBLINGS;

So your window may not be fullscreen, but it also may not have a border, caption etc.

Apart from that, following thro from OnDestroy, MFC destroys menus, threads, etc., and I´m thinking that the OpenGL Irrlicht driver is leaving the window or something set in such a way that a problem occurs within MFC, causing a 5 second delay each time the user closes the view.

As a test, I deliberately abandoned the Irrlicht device (with opengl driver) rather than deleting it, and hey presto, the problem goes away, the MFC window closes immediately (well, a few ms not 5 whole lone seconds!)

So what on earth would the Irrlicht opengl driver be doing that upsets MFC so much?

Someone out there must know... who wrote this driver, excellent piece of work that it is!

Otherwise I have to dig through all this code, MFC and OpenGL driver, hundreds of lines... umpf!

[robmar]

Problem has been linked to the use of the MFC CView hwnd passed into the CreateDeviceEx function call.

m_pParam->WindowId = reinterpret_cast<void*>(hWnd);

If Irrlicht is created in its own window, MFC does not hang-up in the OnDestroy call for 5 seconds, the lag reduces to 600ms if Irrlicht is in its own window.

The OpenGL driver uses the MFC window by getting a Device Context, which is not freed (as far as I could see) on calling CloseDevice, and this may be causing problems in the Windows MFC.

[robmar]

There are clearly problems with the opengl driver under windows in some areas, hence this little gem of a comment in the driver:-

// I get a blue screen on my laptop, when I do not delete the
// textures manually before releasing the dc. Oh how I love this.

i didn´t write that, but I could of!

CloseDevice does not release the DC of the external window, and maybe it should... that only happens when the device destructor is called.

I don´t have time to chase this further unfortunately, but the quick solution would be to let Irrlicht create its own window, and then manage sizing and placement.... just in case anyone else has this problem sometime.

Software developers should be allowed to have double life spans to compensate for all the hours we lose chasing silly problems (in my cased which are at least 60% my own)!

[CuteAlien]

Only 60% bughunting? So lucky ;-) Anyway - you get easier help if you post complete programs which other people can just compile and try out to reproduce things. If you only post 1-2 lines and it doesn't tell anyone something immediately the only way to reproduce would be if someone else writes a whole app and then adds your lines and startes guessing if the code is similar enough to reproduce the same problem. And there's not much of a chance someone does that - nearly no-one has that much time. So try reduce your problem to the minimum that reproduces it and still compiles and post that and it will be way easier for us to help you or find out if we need to fix something in the engine maybe.

[robmar]

Appreciate the tip, but my apps getting sorta complicated, and making a version I could post would take a while. I have a work around, which is letting the device create its own window and then using setwindowpos to overlay it on the view area. Its the quickest solution, or to use D3D, but then I have to rewrite the shaders in HLSL... sometime I really think I should have become a ski instructor instead!

I guess the opengl driver has an issue with the device context of the external window, because not only does it hang MFC for a full 6 seconds on closing the view, but its impossible to reuse the device again, similar comments have been posted by others. Apart from fixing the problem, probably the best option is to dump MFC, but I´ve got so many controls in multi-tab MFC dialogs... prrrr

Why the D3D driver works so perfectly with MFC is anyones guess, maybe D3D is more "compatible" with MFC than OpenGl is, but maybe I´m just guessing, and that rarely works!

[CuteAlien]

I guess the opengl driver has an issue with the device context of the external window, because not only does it hang MFC for a full 6 seconds on closing the view, but its impossible to reuse the device again, similar comments have been posted by others.

Well, I can't tell - I have no test-app for that... (haven't used MFC in the last 10 years or so). Just post one if you can ever reproduce it in a few lines please.

[robmar]

Hi, I´ve traced the delay to MFC´s WM_MDIDestroy SendMessage call, called when the user closes an MFC view window, which is timing out (the timeout for SendMessage is 5 seconds, which is the delay I´m seeing when using OpenGL driver).

OnDestroy is called by this message, and the Irrlicht device is then closed by flagging terminate to its in its own thread, but with opengl as the driver, sendmessage hangs for the full 5 seconds on exiting OnDestroy. The delay occurs between leaving OnDestroy and returning to the MDIDestroy message caller.

I´m not sure why this happens... could be the opengl driver closes before acknowledging the message... as its using the MFC external window, its taken over message handling.

[robmar]

[updated post]
Stepping through the irrlicht windows driver code, on closing the device, there are 2 messages in the queue with hwnd == 0, and given the coding, they get Dispatched.

Is that normal procedure? Dispatching messages with all NULL parameters?

Oops, forgot to RTFM!

ANSWER: Yes, the hwnd used in the PeekMessage is NULL:- MSDN "If hWnd is set to NULL, PeekMessage retrieves messages for any window that belongs to the current thread, and any messages on the current thread's message queue whose hwnd value is NULL (see the MSG structure). Therefore if hWnd is NULL, both window messages and thread messages are processed."

Sometimes there is a 3rd and final msg, WM_QUIT, but not always.

So why would using the opengl driver have this effect, causing a failure to acknowlege the sendmessage that closes the Hwnd Irrlicht is using?

Is it a timing issue in my MFC code? Does the quit message somehow not get removed? Would that cause the SendMessage timeout?

Okay, will try to reproduce in a small MFC app, and post it!

cpp Code: Select all

 
bool CIrrDeviceWin32::run()
{
        os::Timer::tick();
 
        static_cast<CCursorControl*>(CursorControl)->update();
 
        MSG msg;
 
        while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
        {
                // No message translation because we don't use WM_CHAR and it would conflict with our
                // deadkey handling.
 
                if (ExternalWindow && msg.hwnd == HWnd)   // NOTE, if HWnd is NULL, message gets dispatched!!  Is that SOP?
                        WndProc(HWnd, msg.message, msg.wParam, msg.lParam);
                else
                        DispatchMessage(&msg);
 
                if (msg.message == WM_QUIT)
                        Close = true;
        }
 

[CuteAlien]

I wrote it already twice - create an example which other people can test. No one will start debugging if he has to write the application with the bug first as no one has that much spare-time.

[robmar]

I hoped that maybe the person/s that wrote the drivers might have an idea about message handling.

if not, I´ll do what you suggested. thanks

[CuteAlien]

People writing drivers do the same as you - reading msdn documentation and browsing around the web to figure out stuff :-)

[robmar]

I know, I need to get organised, the 5 P´s you know, Planning Prevents Pi** Poor Performance!

MFC is often a nightmare to unravel, all that code to handle windows within windows, controls within controls.

Unfortunately there is no source code for Window´s SendMessage function, the OnDestroy call completes, its called by the same thread that called SendMessage, but on return, somewhere in the windows return code, it looks like its doing that famous five second timeout.

Does it wait those 5 seconds for it´s message to be removed by the called window? Is that how it gets "acknowledged"?

[CuteAlien]

Yeah, 5 seconds is some timeout which Windows does use to find out if an application hangs: http://msdn.microsoft.com/en-us/library ... 85%29.aspx

[robmar]

I found this below, and this is just what´s happening, the SendMessage call in MFC triggered in closing the view delays its return 5 seconds, but only with the opengl driver selected into Irrlicht:

".... By contrast, SendMessage waits up to 5 seconds for the target window to process the message. If the message is not processed within this time, the command finishes and sets ErrorLevel to the word FAIL."

here : http://www.autohotkey.com/docs/commands/PostMessage.htm under "Remarks"

So the big million dollar question is what is causing the delay? What could happen so that SendMessage thinks the message hasn´t been processed?

I thought that sendmessage just called the window function and returned, and that the return signalled completion, but is there something else that signals completion?